I Exposed an API Key: What to Do in the Next Hour

If you exposed a secret API key, replace it now, because deleting the post or commit does not make the old key safe. Start by working out which kind of key it is, since some keys are designed to be public.

This checklist covers the first hour. It is part of our AI-Built Site Rescue hub, and was checked against vendor documentation on 9 November 2026. Vendor screens change, so follow your vendor's current guide where it differs.

Minute 0 to 10: work out what leaked

Do not start deleting things yet. First write down what leaked, where it appeared, and when.

Then check whether the key is meant to be secret.

Stripe says "Only publishable keys are safe to expose outside your application's back end." Supabase says of secret keys: "Never put one in a browser, a shipped application, or source control."

For any other service, treat the key as secret unless that vendor's documentation says otherwise.

Check whether it reached the browser

Some keys leak without anyone posting them. Build tools copy certain variables straight into the code that visitors download.

Vite's documentation says "VITE_* variables should _not_ contain sensitive information such as API keys." Next.js inlines any NEXT_PUBLIC_ variable into the JavaScript sent to the browser.

If a secret sits in one of those variables, treat it as exposed. AI coding tools can put a key there just as a person can, so check rather than assume.

Minute 10 to 20: decide how fast to act

If you see signs someone is using the key, retire it immediately. Supabase's leaked key guide says to do this even though dependent parts of your app will break until you replace it.

Downtime is usually the lesser problem when a key is in active use. Payment keys and database keys deserve the most urgency.

If there are no signs of misuse, you have a little time to do this in order. Move quickly anyway.

Minute 20 to 40: fix the cause and replace the key

Supabase's guide puts fixing the root cause first. It warns that otherwise "the new key can leak the same way."

That might mean moving the key out of browser code, or removing it from a config file. Then follow these steps.

1. Create a replacement key. Use the vendor's dashboard.
2. Update every place that uses the key. Check your hosting settings, serverless functions, background jobs and any third-party tools.
3. Confirm everything works on the new key.
4. Retire the old key. Confirm it no longer grants access.

If it is a Stripe key

Stripe's key rotation steps let you choose when the old key expires. Stripe says that during a normal rotation, "both the old and new keys work for up to 7 days."

That grace period is designed to avoid downtime. For a compromised key, a long overlap also leaves the old key working. Choosing Now deletes the old key immediately, so use a short window or none at all.

Stripe says you can rotate if a key is compromised and you need to block potentially malicious requests. It also recommends restricted keys, which limit what a stolen key can do.

If it is a Supabase key

Create a new secret key under Settings, then API Keys, and move every service to it. Then retire the compromised key, and remember that Supabase says "Deleting a secret key can't be undone."

If the leaked key is a legacy service_role key, Supabase asks for two more steps. Replace the legacy anon key with a publishable key in your clients, and revoke the legacy JWT secret.

Supabase explains why: legacy keys are signed by that secret, so anything still trusting it can accept the leaked key. Also, if you find a missed client later, move it to a new key. Re-enabling the legacy keys would restore the compromised one.

If it was pushed to GitHub

GitHub's documentation says "as a first step you need to revoke and/or rotate that secret." After that, rewriting your history may not even be necessary.

GitHub also warns that "You cannot remove sensitive data from other users' clones of your repository." Commits can stay reachable in forks. So rotating the key is what protects you, not the cleanup.

Minute 40 to 60: look for misuse

Now find out whether anyone used the key while it was exposed.

• In Stripe, open the key's menu and select View request logs.
• In other services, look for usage reports, audit logs or unexplained changes in billing.
• Look for activity from unfamiliar locations, at odd hours, or against data your app never touches.
• Save what you find, with dates, before logs age out.

Stripe's documentation recommends access policies on live keys, so a key can only be used from known sources. Stripe says it blocks a disallowed request and notifies you.

If the key could reach customer data and you see signs it was used, stop and get advice. Breach notice rules vary by state, and we have not covered them here. Talk to a lawyer about what applies to you.

After the first hour

Once the key is replaced, reduce the chance of a repeat.

1. Keep secrets on the server, in your host's secrets vault or environment settings.
2. Use restricted keys with only the permissions each job needs.
3. Turn on GitHub secret scanning, which GitHub says runs automatically for free on public repositories.
4. Review what your AI coding tool can read. Our guide to keeping keys away from Claude Code shows one approach.
5. Check your database rules, since a publishable key only reaches what your rules allow. Read Row-Level Security in plain English.

Next step

If you are not sure what was exposed or how far it went, get a second person involved now. Talk to us if you need help containing and cleaning up, though no one can promise the key was never misused.

Frequently asked questions