My API key leaked. What now?

You pushed a key to a public repo, or got a secret-scanning email, or found one sitting in your frontend bundle. This is a normal thing that happens to careful people. Here's what to do, in order.

Why rotating is the only fix

The instinct is to delete the line, commit, and hope. That doesn't work, for three reasons:

• It's still in your git history. Anyone who clones the repo gets every previous version of that file.
• It may already have been copied. Public repositories are continuously scraped for credentials by automated tools. The window between pushing a key and it being harvested is frequently measured in minutes.
• Forks, caches and mirrors persist. Even a deleted repo can survive in a fork or someone's cache.

So the honest assumption is: if it was exposed, treat it as known. Rotating makes that irrelevant. Nothing else does.

Where to rotate, by provider

Rotating usually breaks your deployed app for a minute, because it's still using the old value. That's fine, and it's the correct order — a briefly broken app is better than a live key in the wild.

Three cases that need more than a rotation

AWS keys

This is the one that generates the horror-story bills. Attackers use stolen AWS credentials to run compute — usually crypto mining — and they do it in regions you've never opened, because that's where you won't look.

After deactivating the key: check the Billing dashboard, then check EC2 in every region, not just yours. Also look at IAM for users or access keys you didn't create — a common move is to create a second set of credentials so revoking the first one changes nothing. If you find charges, contact AWS support; they routinely waive fraudulent usage when you report it promptly.

Supabase service_role keys

That key bypasses Row Level Security completely, so while it was exposed, every row in your database was readable and writable by anyone holding it. Rotate it, then assume the data was read. If it included other people's personal information, you may have a legal obligation to tell them — that's a data breach, not just a leak.

Live Stripe secret keys

Roll it immediately, then review Payments, Refunds and Customers for activity you didn't initiate. Stripe's support team deals with this often and are worth contacting early rather than late.

Then: clean up and prevent the repeat

1. Get it out of the codebase. Move the value to an environment variable, and make sure the file that held it is gone from the working tree. Set the real value in your host's dashboard — Vercel, Netlify, Supabase and the rest all have an environment variables screen. A .env file on your laptop is not read by your host.
2. Make sure .env is ignored. Add .env and .env.* to .gitignore. If .env was already committed, git keeps tracking it until you run git rm --cached .env.
3. Consider rewriting history — but don't rely on it. Tools like git filter-repo or BFG can strip a secret from past commits. Worth doing for tidiness and for anyone cloning fresh. It does not undo the exposure: forks and caches keep their copies. The rotation is what saved you; this is housekeeping.
4. Turn on push protection. GitHub can block pushes containing recognised secret formats, and it's free on public repositories. It catches this class of mistake before it becomes a public one.
5. Check whether anything else is exposed. Keys rarely leak alone. The habit that put one in the code — pasting a value in to get something working — usually put several. Worth a look before you close the laptop.