What website API keys are and why they are risky
API keys are credentials that identify an application or website when it connects to a third-party service such as Stripe, Google Maps Platform, OpenAI, Twilio, or AWS.
They are often treated as simple configuration values, but if exposed, they can be used to trigger charges, access data, or abuse services in your name.
Learning how to secure website API keys is not just about hiding strings in code.
It requires reducing exposure in the browser, limiting what each key can do, and building processes that assume secrets may eventually leak.
Store API keys outside source code
The first rule is straightforward: do not hardcode API keys into HTML, JavaScript bundles, mobile apps, Git repositories, or shared documents.
Anything committed to source control can be copied, mirrored, scanned, and indexed long after you delete it.
For server-side applications, store credentials in environment variables or a dedicated secrets manager.
Common options include:
- AWS Secrets Manager or AWS Systems Manager Parameter Store
- Google Secret Manager
- Azure Key Vault
- HashiCorp Vault
- Platform-specific secret stores in tools like Vercel, Netlify, or Render
For local development, use a .env file that is excluded from version control with .gitignore.
Make sure development, staging, and production environments each use separate keys so a test leak does not expose production systems.
Restrict key permissions to the minimum required
Most modern APIs let you scope keys or issue restricted credentials.
Use that capability aggressively.
A key that can only read a single resource is much safer than one that can create, delete, and modify everything.
Apply the principle of least privilege by limiting:
- Endpoints: allow only the routes the app needs
- Methods: restrict actions like read versus write
- Resources: bind keys to specific projects, buckets, or domains
- Locations: limit usage by IP address or referrer where supported
- Time: use temporary credentials instead of permanent ones when possible
For example, a Google Maps key used only in a web page should typically be restricted by HTTP referrer.
An internal service calling a payment provider may need IP allowlisting and a key with narrowly defined permissions.
Keep secret keys on the server, not in the browser
One of the most important rules in website security is that secret API keys must never be shipped to the client side.
If a browser can see the key, so can users, bots, and attackers inspecting network traffic or JavaScript bundles.
Public keys are sometimes acceptable if the provider designed them for browser use and added protective controls such as origin restrictions, quotas, or signed requests.
Secret keys, however, should stay on a backend server or serverless function that acts as a trusted proxy.
A secure pattern looks like this:
- The browser sends a request to your server
- Your server authenticates the user
- The server calls the third-party API using the secret key
- The server returns only the necessary response data to the browser
This architecture also gives you a central place to log usage, enforce rate limits, and block suspicious traffic.
Use a secrets manager for production workloads
A secrets manager improves security and operational control compared with static files or ad hoc environment variables.
It can rotate keys, audit access, and control which systems may retrieve specific secrets.
Important capabilities to look for include:
- Encryption at rest and in transit
- Role-based access control
- Audit logging
- Versioning and rollback
- Automatic rotation or integration with rotation workflows
Teams working with Kubernetes, Docker, CI/CD pipelines, or microservices should also avoid copying the same key into multiple places.
The fewer locations a secret exists in, the easier it is to manage and revoke.
How to secure website API keys in Git and CI/CD?
Source control and deployment pipelines are frequent leak points.
Developers often accidentally commit credentials to GitHub, GitLab, or Bitbucket, or expose them in build logs and environment dumps during automated deployments.
Use these controls to reduce risk:
- Enable secret scanning in your repository platform
- Install pre-commit hooks that block obvious credential patterns
- Use CI/CD secret stores rather than plaintext pipeline variables where possible
- Mask sensitive values in logs
- Restrict who can read deployment settings and environment configuration
If a key ever appears in a public repository, assume it is compromised.
Revocation and replacement should happen immediately, even if the repository was deleted later.
Add rate limits, quotas, and anomaly detection
Security is not only about keeping attackers out; it is also about limiting damage when a credential is abused.
Most major API providers support quotas, usage caps, or billing alerts.
Configure these before an incident happens.
Useful controls include:
- Daily or monthly spending limits
- Per-key request quotas
- Alerts for unusual traffic spikes
- Logging for failed authentication and excessive use
- IP reputation checks or WAF rules where applicable
Monitoring helps identify abuse patterns such as repeated requests from unfamiliar regions, sudden increases in volume, or calls to endpoints your app never uses.
Rotate keys on a schedule and after any exposure
Key rotation is essential because no storage method is perfect.
Even well-protected keys can be exposed through developer laptops, backups, shared screenshots, browser extensions, or misconfigured servers.
Set a rotation policy based on sensitivity and operational risk.
High-value keys may need frequent rotation, while less sensitive ones can use a longer cycle.
Rotate immediately when:
- A secret is committed to a repository
- A developer leaves the team
- Logs or tickets accidentally reveal the value
- An endpoint or environment is decommissioned
- Abuse or suspicious usage is detected
To avoid outages, test a dual-key rotation process where the new key is deployed and verified before the old one is revoked.
Validate origins, referrers, and IP addresses where supported
Providers often let you bind usage to known origins or source IP addresses.
These restrictions do not make a key invulnerable, but they significantly reduce the chance that a leaked value can be reused elsewhere.
For browser-based integrations, origin or referrer restrictions can stop a stolen key from working on another domain.
For server-to-server integrations, IP allowlisting can ensure that only your infrastructure may call the API.
Be aware that these controls are not universal and should be combined with authentication, quotas, and monitoring.
They are defense-in-depth measures, not standalone protection.
Review logs for accidental exposure
API keys sometimes leak through application logs, debug traces, analytics events, support tickets, or error pages.
Logging should capture enough detail to debug issues without exposing credentials.
Good logging hygiene includes:
- Redacting secrets before writing logs
- Avoiding full request/response dumps in production
- Sanitizing exception messages
- Checking observability tools for sensitive payloads
Search older logs as well as current ones.
A forgotten log archive can still contain a usable key long after the original incident.
Train developers and document a response plan
Strong controls fail if the team does not follow them consistently.
Developers, DevOps engineers, and support staff should know which credentials are public, which are secret, where they are stored, and what to do if one is exposed.
A simple incident playbook should specify:
- Who can revoke keys
- How to create replacements
- Where to update applications and infrastructure
- How to confirm the old key is no longer active
- How to communicate the issue internally
This preparation reduces downtime and makes a security incident manageable instead of chaotic.
Secure API keys by design, not by cleanup
The safest approach is to design systems so that secret credentials rarely reach risky places in the first place.
Keep secrets server-side, scope them tightly, monitor them continuously, and rotate them on a predictable schedule.
Those measures create a practical security baseline for modern websites that depend on external APIs.