API Credential Leakage: A Practical Prevention and Response Guide

API keys and tokens are bearer credentials: anyone who obtains one may be able to use it within the key's permissions. The safest program therefore combines prevention, least privilege, monitoring, and a rehearsed response plan. No single scanner or redaction tool is enough.

Where credentials leak

Common exposure paths include:

• source repositories and pull-request diffs;
• CI/CD logs, build artifacts, and copied configuration files;
• container image layers and build metadata;
• support tickets, chat messages, screenshots, and documentation;
• client-side code, URLs, and telemetry;
• long-lived keys that remain active after their original purpose ends.

Google Cloud's API-key guidance recommends keeping keys out of client code and repositories, restricting their use, monitoring usage, deleting unneeded keys, and rotating keys periodically. GitHub push protection can block supported secrets before they reach a repository, although its documented detection limits mean it should be one layer in a broader control set.

Prevent leaks before code reaches the repository

1. Keep real secrets out of tracked files. Commit a .env.example containing placeholders, not production values.
2. Enable push protection and secret scanning. Treat bypasses as reviewed exceptions, not routine workflow.
3. Use short-lived identities where available. Prefer workload identity or narrowly scoped service credentials over shared, long-lived keys.
4. Restrict every key. Limit it by API, environment, workload, network, or referrer as the provider supports.
5. Review CI output. Avoid commands that echo environments, shell tracing around secrets, and artifacts that copy entire workspaces.

Keep secrets out of container images

Docker documents that build arguments and environment variables are inappropriate for secrets because they can persist in the final image or its metadata. Use BuildKit secret mounts instead:

# syntax=docker/dockerfile:1
FROM alpine:3.20
RUN --mount=type=secret,id=api_token \
    API_TOKEN="$(cat /run/secrets/api_token)" ./fetch-private-dependency

docker build --secret id=api_token,src=./api-token.txt .

Also keep secret files out of the build context with .dockerignore, inspect image history, and scan the finished image before publishing it.

Share configuration safely with Env Sanitizer

Env Sanitizer is a sharing safeguard—not a CI scanner, secret manager, or incident-response substitute. Never paste a real credential into any tool unless you have verified how it processes and stores the data. For repository enforcement, use your platform's secret scanning and a dedicated scanner in CI.

If a credential is exposed

Treat a committed or shared secret as compromised even if the file or message is later deleted.

1. Revoke or rotate the credential immediately. Do not wait for repository-history cleanup.
2. Identify its privileges and exposure window. Determine which services, data, and environments it could access.
3. Review provider and application logs. Look for unexpected source addresses, operations, resources, and usage spikes.
4. Contain affected systems. Disable related sessions or derived credentials when the provider's model requires it.
5. Remove the secret from current content and, where appropriate, history. Coordinate disruptive history rewrites rather than performing them casually.
6. Document the root cause and add a preventive control. Examples include push protection, a narrower scope, shorter lifetime, or a safer build path.

A minimum control checklist

• [ ] No production secrets in tracked files or client bundles
• [ ] Push protection and repository secret scanning enabled
• [ ] Dedicated secret scanning in CI with reviewed exceptions
• [ ] Docker builds use secret mounts, not ARG or copied .env files
• [ ] Keys are restricted, monitored, inventoried, and owned
• [ ] Rotation and revocation procedures are tested
• [ ] Shared configuration is redacted and manually reviewed

Sources

• GitHub Docs: Push protection
• GitHub Docs: Secret scanning detection scope
• Docker Docs: Build secrets
• Google Cloud: Best practices for managing API keys