I leaked my API key. What to do in the next 10 minutes

You committed a key, pasted it somewhere public, or a scan just told you your live site is serving it to anyone who looks. First: this happens constantly, to experienced developers too, and it is very fixable. Second: the clock matters more than the cleanup. Bots scrape public GitHub commits and websites for fresh credentials around the clock — a key that goes public is often tried within minutes, not days.

The one thing that matters: revoke the leaked key and issue a new one right now, before you touch the code. Deleting the commit or file where the key appears does nothing — only revoking the key at the provider makes the leaked value stop working.

Here is the order of operations. Do not reorder it.

Step 1: Revoke the key. Now, before anything else.

Your instinct will be to delete the code, the commit, or the file. Resist it. Deleting where the key appears does nothing about the key itself — anyone who already copied it still has it. The only fix is making the key stop working.

Rotation means two things everywhere: revoke the leaked key and create a new one. Where to do that for the common providers:

• OpenAI — platform.openai.com/api-keys: delete the leaked key, create a new one. Then check the Usage page for spend you don't recognise.
• Anthropic — console.anthropic.com → API keys: same drill, revoke and re-create.
• Stripe — Dashboard → Developers → API keys → "Roll key" on the secret key (sk_live_...). Rolling gives you a grace window to swap the new key into your app. (If what leaked starts with pk_live_, breathe out — publishable keys are designed to be public. Only sk_ and rk_ keys are secrets.)
• Supabase — the key that matters is service_role. Project Settings → API → regenerate the JWT secret, which invalidates both the anon and service_role keys — then update your server config with the new ones. (More on the anon/service_role difference in this guide.)
• AWS — IAM → Security credentials: deactivate the access key, create a new one, delete the old one once nothing uses it. Then check CloudTrail and Billing for activity you don't recognise — leaked AWS keys get used for crypto-mining within hours.
• GitHub tokens — Settings → Developer settings → revoke. (If the token leaked in a public repo, GitHub's own secret scanning may have auto-revoked it already — check your email.)

For anything else, search "provider rotate API key". Every serious provider has this page.

Step 2: Swap the new key in — server-side this time

Put the new key in an environment variable on your hosting platform (Vercel, Netlify, Fly, Railway — they all have an "Environment Variables" settings page), redeploy, and confirm the app works.

While you are there, check where the old key lived. If it was in your frontend code, a config file that ships to the browser, or an env var with a public prefix like NEXT_PUBLIC_ or VITE_, the new key will leak exactly the same way. Keys belong on the server: in an API route, a server function, or a backend — never in code the browser downloads.

Step 3: Check whether it was used

Don't skip this because the answer is scary. Every provider shows usage:

• OpenAI/Anthropic: usage dashboards — look for spikes you didn't cause.
• Stripe: Developers → Logs — API calls you didn't make.
• AWS: CloudTrail + the billing page.
• Supabase: Database → Logs, and look at your data for rows you didn't create.

If you find real misuse: rotate anything else that key could reach, and contact the provider's support — they deal with this daily and are generally helpful about fraudulent usage on leaked keys.

Step 4: Understand that git history is forever

If the key was ever committed, removing it from the current code does not remove it from history — every clone of the repo still contains the old commit, and if the repo was public, assume it was scraped. This is why Step 1 is rotation, not cleanup: a leaked key is dead the moment you revoke it, no matter how many copies of it exist.

Rewriting git history to scrub the key is optional hygiene, only worth the trouble for private repos going public later. Rotation already solved the security problem.

Step 5: How to stop it happening again

Three habits cover almost every leak:

1. .env in .gitignore, always — and check with git status that it shows as ignored before your first commit. (How .env files end up public covers the failure modes.)
2. Nothing secret in frontend code or public env prefixes. If the variable name starts with NEXT_PUBLIC_, VITE_ or REACT_APP_, it ships to every visitor's browser.
3. Check what your live site actually exposes. You can't see your client bundle by reading your source — but anyone on the internet can read the bundle. OpzyAI's free scan reads your site exactly the way a stranger's browser would and flags any keys, exposed files or leaky configs it finds, in about 15 seconds, no account. If you work in Cursor or Claude Code, the MCP server runs the same check from inside your editor before you ship.

The honest summary: leaking a key costs you ten stressful minutes if you rotate fast, and potentially a real bill if you don't. Rotate first. Everything else is optional.