What to do when an API key or password is found in your code

Do not start by deleting the line. Once a key has sat in a repository, copies live in clones, forks, build caches, backup drives and the laptops of every developer who ever pulled the code. Removing the file changes nothing about who already holds it. Speed matters more than tidiness.

Open the provider’s console and disable the old key. Create a replacement and deploy it. For a database password, change it on the server. Update the application settings in the same window. Warn the team first. Mobile users on the old build will see errors until they update, and webhook senders will start failing. Nobody should waste an hour debugging a failed login.

Expect a short outage. A planned ten minute break beats a quiet leak that runs for months while invoices and customer records sit open to anyone holding the key.

Rotation closes the door. It does not tell you who walked through. Ask the provider for the usage history of the old key, starting from the day it first appeared in code.

Look for calls from unfamiliar addresses, odd hours, regions you do not serve and actions your app never performs, such as creating new users or listing storage buckets. Check the bill for sudden spikes too. Cloud providers keep such trails. AWS CloudTrail and Google Cloud audit logs are the usual places to look.

Write down what you find, even when it is nothing. Save screenshots of the log filters you used, with dates, in a folder the security owner controls. That record matters if a customer or regulator asks later.

A secret removed in a later commit stays readable in the earlier one. Tools such as git filter-repo or BFG Repo-Cleaner rewrite history to strip it. Every contributor must then re-clone and force the old branches out of their local copies. Give notice first.

Do not forget what sits outside the repository. Search old Docker images, CI logs, Postman collections and wiki pages for the same string. Check the APK or IPA files already published too. A mobile build carries its strings in plain view. Unpacking takes a minute. Stale copies hide there. Terraform state files and exported Kubernetes manifests are favourite hiding places.

The key is revoked already, so this is housekeeping. Do it anyway. Never let it replace the revoke step.

Secrets belong in a managed store such as a cloud secrets manager or a vault, read at start time through environment settings. The code holds the name of the secret. It never holds the value. A .env file kept out of version control is a start, not an end.

Give each environment its own keys, so a developer’s test key has no power over production data, customer files or the live payment account. Limit every key to the single action it needs. Set an expiry where the provider allows one.

For a mobile app, assume the build is public. Route sensitive calls through your own server, which holds the real key and checks who is asking before it forwards anything to the provider.

Add secret scanning to the repository and to the pre-commit hook; a push that contains a key pattern should fail with a message naming the file. Gitleaks and the scanning built into major code hosts do this job; the scan should also run in the build pipeline, as a second net.

Add one line to code review: references only, no values in the diff; run a scan across the full history every quarter to catch what slipped through. Short. Strict. Boring.

Today, list every key your applications use. Note where each lives. Rotate the oldest.