API Key Exposed in Code — What to Do Right Now

Git stores every version of every file you have ever committed. When you commit a file containing a secret, that commit object is stored in the repository's object database. Even if you immediately create a follow-up commit that deletes the file or removes the key, the original commit continues to exist. Anyone with access to the repository can check out that commit, view the file, and read the secret.

This permanence is especially dangerous for public repositories. GitHub, GitLab, and Bitbucket provide public repositories that can be cloned by anyone on the internet. If a secret is pushed to a public repository for even a few seconds before being deleted, automated bots that continuously monitor public repositories for high-value credentials may already have captured it. This is not a hypothetical — AWS, Stripe, GitHub, and other providers all operate secret scanning systems that monitor public repositories in real time and notify both the affected user and the service provider.

For private repositories, the risk is lower but not zero. Every team member with read access to the repository can see the full git history. If the repository is ever made public, forked by a security researcher, or its access controls are misconfigured, the exposed key becomes public. Past employees who had repository access retain the git objects they cloned before losing access.

Environment variables are the standard solution. In Node.js, process.env.MY_KEY reads a value injected by the operating system's process environment rather than sourced from a file in the repository. In production environments like Vercel, Heroku, and AWS, secrets are configured through the platform's secrets management interface and injected as environment variables at runtime. The source code never contains the secret value — only the variable name.

Start by searching git history for patterns that look like secrets. The command git log -p --all -- followed by a file path shows the full diff history for that file. For a broader search, git log --all --full-history -- .env shows all commits that touched any .env file. Use git show <commit-hash>:.env to view the file content at a specific historical commit.

For automated scanning, use tools like gitleaks, truffleHog, or git-secrets. Gitleaks scans the full git history of a repository for common secret patterns: API keys, tokens, private keys, and connection strings. Run it as gitleaks detect --source . to scan the current repository. It outputs a report of every detected secret with the commit hash and line number. Install it as a pre-commit hook to prevent future commits with detected secrets.

GitHub provides built-in Secret Scanning for all repositories (free and paid). Navigate to your repository's Settings tab, then Security and Analysis, and ensure Secret Scanning is enabled. GitHub scans every push for known API key formats from major providers including AWS, Stripe, Google, GitHub, Slack, and hundreds of others. When a secret is detected, GitHub notifies the repository owner and, for public repositories, notifies the service provider so they can revoke the key.

Check your CI/CD logs as well. Pipeline logs often capture environment variables in debug output, especially when a step runs with verbose logging or when an error causes a full environment dump. Review recent build logs for any that contain long alphanumeric strings resembling API keys. Most CI platforms (GitHub Actions, CircleCI, GitLab CI) automatically redact known secret formats in log output, but custom secrets or unusual formats may slip through.

Step one: rotate the key immediately. Do not wait to clean up the code or git history first. Go to the API provider's dashboard and revoke the exposed key, then generate a new one. This ensures the exposed credential is useless even if someone has already captured it from your repository. For AWS, use the IAM console to deactivate the access key. For Stripe, revoke the key in the Developers section. For OpenAI, delete the key in the API keys management panel.

Step two: update your environment configuration. Add the new key to your local .env file and to your production environment (Vercel, AWS Secrets Manager, Heroku Config Vars, etc.). Test that the application works with the new key before proceeding to history cleanup. Confirm the old key is fully revoked by checking that any application still configured with it fails to authenticate.

Step three: remove the secret from git history. The recommended tool for this is git filter-repo (the modern replacement for git filter-branch). Run: git filter-repo --path .env --invert-paths to remove the .env file from all commits. For removing a secret from a specific file without removing the file itself: git filter-repo --textconv-path script that replaces the secret with a placeholder. After rewriting history, force-push to the remote with git push --force-with-lease and notify all team members to re-clone the repository, as their local clones now have diverged history.

Step four: add preventative measures so this does not happen again. Install gitleaks as a pre-commit hook: gitleaks protect --staged will scan staged files before each commit. Add .env* to .gitignore and commit a .env.example file with placeholder values. For Next.js projects, review every environment variable that has the NEXT_PUBLIC_ prefix — those values are embedded in the client-side JavaScript bundle and visible to end users, so only non-sensitive values should carry that prefix.

Public repository forks present a problem that git history rewriting cannot solve. If your repository was public and another user forked it before you removed the secret, their fork still contains the original git objects including the commit with the exposed key. GitHub does not automatically propagate history rewrites to forks. Revoking the exposed key is the only effective remediation — the historical data in forks cannot be removed.

GitHub allows you to contact support to quarantine a repository that has had sensitive data exposed, which can help prevent further forking while you remediate. However, this is a time-sensitive process and any forks created before quarantine retain the data. The lesson is that rotating the key is not optional — it is the one action guaranteed to make the exposed credential useless regardless of how many copies exist.

Docker images are a frequently overlooked vector. If a secret is added to a Docker image as an environment variable at build time using ENV MY_KEY=secret, it is baked into the image layer and visible to anyone with access to pull the image. Even if the layer is not the top layer, docker history and docker save can extract it. Secrets should never be provided to Docker builds with ARG or ENV — they should be injected at container runtime via the orchestrator (Kubernetes secrets, Docker Swarm secrets, or the platform's environment variable injection).

CI/CD artifact storage is another risk. Build artifacts (zip files, compiled binaries, log archives) stored in CI systems sometimes capture environment variable values in build logs or configuration files. Review what your CI system stores as artifacts and for how long. Many CI platforms allow you to configure log redaction patterns to mask secrets that are not automatically detected.

The most dangerous mistake is deleting the file or commit without rotating the key first. Deleting the .env file from the repository makes the secret harder to find in git history, but anyone who already cloned the repository has the key in their local object store. More importantly, automated scrapers may have already captured the key. Rotation must come first.

Another common mistake is using git revert instead of git filter-repo to remove a secret. git revert creates a new commit that undoes the changes, but it does not remove the original commit from history — it simply adds a new commit on top. The secret is still visible in the reverted commit. Only history rewriting with git filter-repo or equivalent actually removes the secret from the repository's object database.

Adding .gitignore entries for .env after the file has already been committed is ineffective. Git ignores files that have not yet been tracked, but once a file is in git's index, .gitignore has no effect on it. To stop tracking a previously committed file, you must run git rm --cached .env to remove it from the index, then commit the removal. After that, .gitignore will prevent future accidental additions.

Trusting that a private repository is safe because only trusted team members have access is a false sense of security. Access controls can change — employees leave, repository visibility can be accidentally changed to public, and GitHub/GitLab permissions can be misconfigured in complex organizations. Treat every secret that enters a repository as if that repository could become public at any time, and design your secret management accordingly.

Establish your .gitignore and environment variable patterns before the first commit. The GitHub gitignore templates for Node.js, Python, and other languages already include .env and .env.local patterns. Use the appropriate template when creating a repository. Add a .env.example file that lists all required environment variables with placeholder values — this documents the configuration interface without revealing any actual secrets.

Use a secrets manager for production deployments rather than storing secrets in environment variable configuration files on servers. AWS Secrets Manager, HashiCorp Vault, Doppler, and 1Password Secrets Automation all provide APIs for retrieving secrets at runtime. Your application authenticates to the secrets manager using a role or service account credential (which itself should never be a static API key), and retrieves the actual secrets at startup. This approach means rotating a secret requires only updating the secrets manager entry, not re-deploying the application.

Install pre-commit hooks that scan staged files for secrets before every commit. Gitleaks and git-secrets both support pre-commit mode. With Husky or lefthook, add the scanner to your project's git hooks so every developer on the team runs the check automatically on every commit. Configure CI to run the same scan on every pull request as an additional check.

For Next.js projects specifically, understand the NEXT_PUBLIC_ naming convention deeply. Any environment variable prefixed with NEXT_PUBLIC_ is intentionally embedded in the client-side JavaScript bundle and visible to anyone who inspects the page source or JavaScript files. It is appropriate for public API endpoints, analytics IDs, and public configuration values. It is never appropriate for secrets, private API keys, database credentials, or signing secrets. All sensitive values must use server-side environment variables without the NEXT_PUBLIC_ prefix.