I leaked an API key in my vibe-coded app. What do I do now?

Last updated: October 23, 2026

Not sure if a key is exposed? Run a free SniffPup scan of your live URL. It passively checks your HTML and JavaScript for secret keys (masked in the report) and tests public files like /.env and /.git/config. Free to scan, no signup.

Short answer: don't panic, and don't just delete the line. Rotate the key first, check what it was used for, move the code that needs it to the server, redeploy, then re-check your live site. The order matters: a key that reached a browser or a public repo should be treated as copied.

Step 1: Rotate or revoke the key at the provider

Create a new key, switch your server to it, then revoke the old one. Where to do it:

Step 2: Check what the key was used for

Look at the provider's usage or logs page for calls you don't recognize, unusual spend or new resources. For a Supabase secret key, check your tables for rows that were changed or deleted, and your auth users for accounts you didn't expect. If customer data may have been read, write down what you found and when.

Step 3: Move the code that needs the key to the server

Anything in a VITE_ or NEXT_PUBLIC_ variable is built into the JavaScript every visitor downloads. Put secret keys in a Supabase Edge Function, an API route or a serverless function, and have the browser call that instead. A prompt you can paste into your AI builder:

Move every call that uses a secret API key into a server-side function. The browser must never receive the key. Read the key from a server-only environment variable, not a VITE_ or NEXT_PUBLIC_ one, and check the signed-in user before doing the work.

Step 4: Clean up where it leaked

Step 5: Redeploy and re-check from the outside

Redeploy, then scan your live URL again. Old JavaScript files can linger on a CDN, so check the version visitors actually get. If you use Supabase, also confirm Row Level Security is on for every table with the Supabase RLS checker guide, since a leaked secret key bypasses RLS entirely.

What SniffPup checks, and what it doesn't

SniffPup reads only what your live site serves to the public: secret key patterns in HTML and same-origin JavaScript, public .env, .git and source map files, and security headers. It never uses a key it finds. It can't see your private repo, your server code or a provider's usage logs, so steps 1 and 2 are always on you. A score of 100 means no issues were found in our checks, not proof of security. For a full pre-launch list, see the 10-point vibe-coded app security checklist.

FAQ

Is deleting the key from my code enough?

No. Once a secret key has been served to a browser, pushed to a public repo or exposed in a public file, assume someone has a copy. Deleting it from your code doesn't revoke it. Rotate or revoke the key at the provider first, then remove it from your code.

Do I need to rotate my Supabase anon key?

Usually not. The anon or sb_publishable_ key is meant to be public, and Row Level Security is what protects your data. The service_role and sb_secret_ keys are the ones that must never be public; if one leaked, rotate it right away.

If I make my GitHub repo private, is the key safe again?

No. Making a repo private or rewriting git history doesn't un-leak a key that was already public. Rotate the key at the provider. Cleaning history is still worth doing so the old key isn't lying around.

How do I check my live site no longer exposes the key?

Redeploy, then run a free SniffPup scan of your live URL. It checks your HTML and same-origin JavaScript for secret key patterns (masked in the report) and tests common public files such as /.env and /.git/config. A score of 100 means no issues were found in our checks, not proof that your app is secure.

A clean report is not a guarantee of security.

Run a free scan →