TL;DR: Rotate the key first. Not after you check the logs. Not after you find the leak. First. Then find where it leaked, check the provider dashboard for abuse, and move the call behind your own server so it cannot happen again. The exact rotation steps for Stripe, Supabase, and OpenAI are below. Work the order and you will be fine.
So you found a live key somewhere public — a repo, a browser bundle, a pasted log — and typed "exposed api key what to do" into a search bar. Take a breath. This happens to a lot of founders. Most ship the fix the same night. The steps are not hard. What matters is the order. This page is the calm version.
The hour, at a glance
| Minutes | Step | Goal |
|---|---|---|
0–10 | Rotate the key | The old key stops working. The leak stops mattering. |
10–25 | Find the leak | Know how it got out: repo, bundle, or logs. |
25–40 | Check for abuse | Read the provider dashboard for spend and odd traffic. |
40–60 | Move it server-side | Make the same leak impossible next time. |
Step 1: Rotate the key. Now.
Rotate means five things. Open the provider dashboard. Create a new key. Revoke the old one. Put the new key in your production env vars. Redeploy. Do it even if you think nobody saw the key. You will never be sure, and bots scan public code all day. A key rotated in ten minutes is a non-event. A key you watched for a week is an incident.
Two traps to avoid. First: updating your local .env file is not rotation. Production has to get the new key and redeploy, or your live app breaks while the old key keeps working. Second: deleting the key from your code is not rotation either. The old key stays valid at the provider until you revoke it there.
Stripe key exposed: rotation steps
A leaked sk_live_ key is the highest-stakes case. It can move money, issue refunds, and read customer payment data.
- Open the Stripe dashboard › Developers › API Keys. Click Roll key on the secret key. Stripe issues the new key and revokes the old one in the same screen.
- Put the new key in your server's env vars and redeploy.
- Check Stripe's logs for charges, refunds, or payout changes made while the key was live.
- Re-issue the new key as a restricted key with only the scopes your app uses. Most apps need a handful, not all of them.
The browser should only ever see the publishable key. All charge and refund logic belongs on your server.
Supabase key exposed: rotation steps
Supabase has two keys, and the difference is the whole story. The anon key is meant to be public. The service role key is not — it skips Row Level Security and can read every table. If you are not sure which one leaked, read our anon key vs service role key guide first.
- Open your Supabase project › Settings › API. Rotate the service role key. Update your backend env vars and redeploy.
- Check Row Level Security on every table. RLS on, policies owner-scoped, no
USING (true). A leaked anon key is only as safe as your policies. That exact failure drove CVE-2025-48757, which exposed 170+ AI-built apps. - Run our free Supabase RLS checker if you are not sure every table is locked down.
- Move every admin query behind your backend so the service role key never ships to a browser again.
OpenAI key exposed: rotation steps
AI keys are usually caught by a billing alert, not a security alert. That is the tell.
- Open the OpenAI dashboard › API Keys. Revoke the leaked key and create a new one.
- Check the usage tab for spend you do not recognize, odd models, or traffic outside your normal hours.
- Set a hard monthly usage cap while you dig, so any second leaked copy has a ceiling.
- Proxy every model call through your backend. A frontend that calls the API with the key attached publishes that key to every visitor.
Step 2: Find the leak
The key is dead. Now find the wound, in this order:
- Git history. Search past commits, not just the current branch. A key removed today still sits in a commit from three months ago. Scrub it with
git-filter-repo. - The client bundle. Open your live site, view source, and search the served JavaScript for key prefixes like
sk_liveandservice_role. Our guide on finding exposed secrets in AI bundles walks through this step by step. If the key shows up here, it was never server-side at all. - Public repos and forks. If the repo was ever public, even for a day, assume it was indexed and copied.
- Logs and error tools. Some tools capture full request payloads, headers included. Search them for the key.
One more thing. AI editors repeat patterns. If a key was hardcoded in one file, search the whole codebase for the same shape. One leaked key is rarely alone.
Step 3: Check for abuse
This is the step people skip because it is the least fun. Skipping it is how a small leak becomes a huge bill. Open the provider's usage page for that key. Look for three things: spikes in volume, traffic from places you do not serve, and use outside your normal hours. Do not just look for errors. An attacker using your key looks exactly like you, so watch volume and pattern, not failures.
What you find decides what happens next. Nothing odd: write down what you checked and move on. Strange spend or traffic: contact the provider's support. If the key could reach personal data, treat it as a possible data incident. More on that below.
Step 4: Move the call server-side
Rotation fixed today. It did not fix the reason the key leaked. The reason is almost always the same: the API call ran in the browser. The fix is one rule. The browser talks to your server. Your server holds the secret and talks to Stripe, Supabase, or OpenAI. The key never travels to the client.
While you are in there, close the two gaps that make a leak worse. Add a rate limit on the new server route. A leaked key with no throttle is how one key becomes an unbounded bill. Our free API rate limit checker tests an endpoint in under a minute. And set your security headers, which raise the cost of turning any future slip into a takeover.
Why this happened to your app
If an AI tool built your app, this was close to the default outcome. Lovable, Bolt, Cursor, and v0 wire the API call the fastest way that makes the demo work — usually straight from the frontend, key attached. Nothing in the pipeline flags it.
The scale is on record. Symbiotic Security scanned 1,072 AI-built apps: 98% had at least one flaw and 16% had critical issues. CMU's SusVibes study found 61% of AI-written code carried at least one security flaw. Across the 100 AI-built apps we scanned, the average Launch Readiness Score was 42/100. Secrets in the bundle were a constant finding. If you built on Lovable, our guide to securing API keys on Lovable covers the platform-specific fix, and the full picture lives in our vibe coding security guide.
The compliance angle
If the key could reach personal data — emails, chats, payment details — this is more than an engineering task. Under GDPR you must check whether the leak allowed access to personal data. Write that down, even if you decide no report is needed. The duty follows where your users live, not where your company sits. And if your app has an AI feature with EU users, the EU AI Act's Article 50 transparency duties apply from August 2, 2026, with fines up to €15 million or 3% of turnover for that tier. Our Compliance Wing covers both, starting with a $799 Compliance Score. Our GDPR guide explains the write-up in plain terms.
After the fire is out
You rotated the key, found the leak, checked the logs, and moved the call server-side. Good. Now answer the bigger question: what else is sitting exposed? A key rotation fixes one leak, not the pattern that caused it.
The free scan answers that in about a minute. It scores your live URL out of 100. It flags exposed secrets, missing rate limits, RLS gaps, and header gaps. The full Launch Readiness Audit is $499 one time — every finding in a branded report, ranked with time estimates, benchmarked against 200+ audited apps, each item senior-reviewed. That is the difference between closing an incident and closing the class of incident.
FAQ
My API key was exposed on GitHub. What do I do first?
Rotate the key in the provider dashboard before anything else. Then scrub it from Git history with a tool like git-filter-repo. Deleting it from the latest commit is not enough. The old commits still show it.
Do I need to rotate a key if I am not sure anyone saw it?
Yes. You will never be sure. Bots scan public code all day, and old keys stay valid until someone revokes them. Rotation costs you ten minutes. Guessing wrong can cost you your database.
How fast do leaked keys get found?
Fast. Bots watch public commits around the clock, and a key pushed to a public repo can be tried within minutes. Treat any public leak as found, no matter how short it was.
Is a Stripe key leak worse than a Supabase key leak?
They are bad in different ways. A Stripe secret key can move money. A Supabase service role key skips Row Level Security and can read your whole database. Rotate either one right away and check the provider logs.
Does an exposed API key count as a GDPR incident?
It can, if the key gave access to personal data. You must check what the key could reach and write that down, even if you decide no report is needed. The duty follows your users, not your office.
What stops this from happening again?
Move every secret call behind your own backend. The browser talks to your server. Your server holds the key. If the frontend can read a key, so can every visitor. That rule has no exceptions.
Was this the only exposed secret?
Scan your live URL free. Exposed keys, rate limits, RLS, and headers checked in about a minute. No code access.
Run the free scanOne hour, four steps, in order: rotate, find, check, move. You have already done the hard part by acting tonight instead of hoping. Finish the hour, then scan the rest of your app so the next leak never gets its hour at all.