It happens to professionals too: a secret key ends up on GitHub, in a screenshot, or in your site's front end where anyone can read it. If you're wondering what to do after a leaked API key, here's the order that matters. Don't panic, but don't wait either.
Step 1: revoke or rotate the key first
Deleting the key from your code is not enough. Once a key has been public, assume someone copied it. Bots scan public GitHub for keys constantly.
Log in to the provider (OpenAI, Anthropic, Stripe, Supabase, your email service, wherever the key came from), find the API keys page, and either delete the leaked key or "roll" (rotate) it. This makes the old key useless. Then create a new one.
Do this before anything else. Everything below is cleanup.
Step 2: put the new key in the right place
Put the new key only in:
- your
.env.localfile on your computer (never committed), and - your hosting provider's environment variables page (for example Vercel's).
Then redeploy so your live site uses it. On Vercel, changing a variable doesn't affect the site that's already live until you deploy again; see fixing environment variables on Vercel.
Step 3: check for damage
Look at the provider's usage or billing page for activity you don't recognize. For payment providers, check for unexpected charges or refunds. For databases, look for data you didn't create or that went missing. If you see something wrong, contact the provider's support and say the key was exposed; many have a process for this.
While you're there, set a spending limit or budget alert if the provider offers one.
Step 4: clean up where it leaked
- GitHub: remove the key from the code and commit. The old key still exists in your git history, which is why Step 1 (revoking) matters most. If the repository is public and you're unsure, make it private.
- Front end: if the key was in browser code (often behind a
NEXT_PUBLIC_orVITE_name), move the feature that uses it to the server, so the browser never sees the secret. - Screenshots or chats: delete them where you can, but rely on the revoke.
Step 5: stop it happening again
- Make sure
.env.localand.envare listed in your.gitignorefile. - Add a rule to your AI: never put secrets in code, never use a public prefix for secrets. See Cursor rules for beginners.
- Before each launch, run through our vibe coding security checklist.
Not every key is secret
Some keys are designed to be public. The Supabase anon or publishable key, for example, is meant to sit in your front end, and the real protection is your database rules. Read is your Supabase anon key safe to expose? before rotating something that didn't need it. If the leaked key is one labeled secret, service role, or private, treat it as an emergency.
A prompt for your AI
Search this whole project, including config files, for anything that
looks like an API key, token or password. For each one, tell me the file,
whether it is meant to be public or secret, and whether the browser can
see it. Change nothing.
Get the safety rules ready-made
Our free starter pack includes a "secrets stay secret" rule for Cursor and Claude Code. The Ship-Safe Starter Kit adds a .env.example template and a full pre-deploy security checklist.
Written with AI assistance and reviewed by a human. General guidance, not professional security advice.
Want these rules ready-made?
The free starter pack has them, set up for Cursor and Claude Code.