API Key Leaks: Detection, Response, and Prevention

An API key is a credential. If a copied key is sufficient to call a provider, anyone who obtains it may be able to use the permissions and quota attached to it. The impact depends on the provider and the key's restrictions: exposure can lead to unauthorized data access, service abuse, or unexpected charges.

This guide covers the practical questions: where keys escape, what to do first, what secret scanners can and cannot prove, and how to reduce the blast radius before a leak happens.

Where API keys leak

Source control and build artifacts

A key can enter a repository through application code, a committed .env file, a test fixture, infrastructure configuration, or generated output. Deleting it in a later commit does not remove the earlier object from Git history or from existing clones.

Keys also leak without being committed. Shell tracing, verbose build output, source maps, uploaded artifacts, and container image layers can preserve values that were available during a build.

Logs, URLs, and support workflows

Debug output and error reports may capture request headers, environment values, or configuration objects. Keys placed in URL query parameters can also spread through browser history, access logs, monitoring systems, and referrer data. Google Cloud's current API-key guidance recommends sending its keys in the x-goog-api-key header or through a client library instead of a query parameter.

Configuration copied into a ticket, chat, document, or public paste can outlive the incident that prompted the share. Redaction should happen before the text leaves the controlled environment.

Browser and mobile applications

Code and configuration delivered to an end user's browser or device should be treated as observable. Some providers intentionally support public client keys, but those keys must be designed for that use and constrained using the controls the provider offers.

Do not assume that every string called an “API key” has the same security properties. A publishable identifier, a restricted browser key, and an unrestricted server credential require different handling. Follow the issuing provider's documentation.

What to do when an API key leaks

1. Revoke or rotate the exposed credential

Containment comes before repository cleanup. GitHub's sensitive-data removal guidance says to revoke or rotate a secret first. Once the old key no longer authorizes access, an attacker cannot keep using that value.

Create the replacement with only the permissions, environments, and APIs the workload needs. Update legitimate consumers through the approved secret-delivery path; do not paste the new value into the same channel that leaked the old one.

2. Review usage and bound the incident

Use provider-side audit and usage logs where available. Record:

• the first and last suspicious use;
• the source identities, networks, regions, and user agents;
• resources read, changed, created, or deleted;
• downstream credentials or sessions the key could create;
• charges, quotas, and alerts affected by the activity.

Preserve relevant evidence before changing logs or systems. Rotate related credentials based on evidence and shared exposure, rather than indiscriminately replacing every secret.

3. Remove the value from active systems

Remove the exposed value from the current branch, build configuration, artifacts, logs, tickets, and documentation you control. Verify that deployment caches and runtime configuration no longer supply the revoked key.

History cleanup is a separate decision. Rewriting Git history changes commit hashes, requires coordination with every clone, and can reintroduce the secret if an old branch is merged. Because revocation removes the credential's access, a disruptive history rewrite is not automatically required.

4. Fix the leak path

Identify why the credential reached the exposed location. A complete fix may require a secret store, log filtering, build-secret mounts, narrower CI permissions, push protection, or a support-sharing checklist. Add a regression check for the actual failure mode.

What secret scanning can and cannot tell you

GitHub secret scanning detects supported credential patterns across repository history. Push protection can block supported patterns before they reach the repository. Custom patterns can cover organization-specific formats.

These controls reduce risk, but a clean scan is not proof that no secret exists:

• not every provider or credential format is supported;
• generic and custom patterns can produce false positives or miss unusual values;
• some credentials require paired values or context;
• detecting a string does not reconstruct every place it was copied;
• only provider-side revocation makes an exposed credential unusable.

Use scanning as one layer alongside least privilege, short lifetimes, monitoring, and a rehearsed response process.

Prevent API key leaks

Prefer workload identity or short-lived credentials

When a platform supports workload identity, OIDC federation, or dynamically issued credentials, use it instead of distributing a long-lived static key. Short lifetimes narrow the useful window after exposure and reduce manual key handling.

Store and deliver secrets deliberately

Use the platform's secret store or a dedicated secrets-management system. Limit who and what can read each secret, keep production values out of developer laptops where practical, and prevent untrusted pull requests from receiving privileged CI credentials.

Environment variables can transport a secret into a process, but they are not a complete secret-management system. See Are Environment Variables Secure? for the runtime and operational tradeoffs.

Restrict each key at the provider

Apply both application restrictions and API or permission restrictions when the provider supports them. Google Cloud's API-key best practices explain that restrictions limit how a key can be used and reduce the impact of compromise.

Use a separate key for each application and environment. Disable unused APIs, delete unused keys, and apply quotas or spend alerts where available. Restrictions reduce blast radius; they do not make a publicly exposed server credential safe.

Keep keys out of logs and URLs

Redact credential-bearing headers and configuration fields before logging. Avoid printing whole environment objects. Do not send keys in URL query parameters unless a provider explicitly requires it and you understand the exposure path.

Scan before and after commit

Use editor, pre-commit, CI, repository, and provider-side detection where appropriate. Enable push protection for supported and high-confidence custom patterns. Treat scanner bypasses as reviewable exceptions, not routine workflow.

API key security checklist

• [ ] Each key has one documented owner, workload, environment, and purpose.
• [ ] Permissions and enabled APIs are limited to what the workload needs.
• [ ] Provider-side application restrictions are enabled where appropriate.
• [ ] Long-lived keys are replaced by workload identity or short-lived credentials where possible.
• [ ] Production secrets are delivered through an approved secret store.
• [ ] Untrusted builds and pull requests cannot access privileged secrets.
• [ ] Logs, URLs, errors, source maps, and artifacts are checked for credential exposure.
• [ ] Secret scanning and push protection cover supported and custom formats.
• [ ] Usage alerts, quotas, or spend alerts are configured where available.
• [ ] Revocation, evidence preservation, consumer updates, and cleanup are rehearsed.

Related local tools and guides

• Mask likely secrets before sharing with the Safe-to-Share Sanitizer.
• Review environment delivery and runtime risks in Are Environment Variables Secure?.
• Follow the response workflow in Environment Variable Leaks: How Secrets Escape and What to Do.

Primary guidance

• GitHub: Removing sensitive data from a repository
• GitHub: Secret scanning
• OWASP Secrets Management Cheat Sheet
• Google Cloud: API key best practices