Guide Supabase
My Supabase secret key is in my frontend. What now?
Short answer
If the key starts with sb_secret_ or is the legacy service_role key, treat it as compromised: it bypasses every Row Level Security policy. First fix how it leaked, so the key only lives in server-side code. Then create a new secret key, replace the old key everywhere, confirm everything uses the new one, and delete the old secret key. For a leaked legacy service_role key, deactivate the legacy keys, which also turns off the legacy anon key, so move your frontend to the publishable key first. The anon or publishable key (sb_publishable_) is meant to be public and isn't a leak.
Which key is it?
The Supabase anon key (or the newer publishable key, sb_publishable_...) is designed to be public. Your data is protected by Row Level Security policies. The key that must never appear in frontend code is the service_role key (or the newer secret key, sb_secret_...), because it bypasses RLS.
Where it leaks
- Client bundle
VITE_-prefixed env vars (NEXT_PUBLIC_in Next.js)- Repo history
Rotate, in Supabase's order
- Fix the root cause first
- Create a new secret key (Settings > API Keys)
- Replace the old key everywhere
- Confirm every component uses the new key
- Delete the old secret key (can't be undone), or for a legacy service_role key deactivate the legacy keys (reversible; move the frontend off the legacy anon key first)
Tip from Supabase: one secret key per backend component, so a leak means rotating only that one.
Git history
Rotating comes first. Once the old key is deleted (or, for a legacy service_role key, the legacy keys are deactivated) it's useless, even though copies stay in your repo's history, clones and forks. Rewriting history is optional extra work with side effects (PatchAndShip treats it as a separate request).
Check RLS anyway
A leaked secret key bypasses every RLS policy, so fix both: Supabase RLS checklist for Lovable, Bolt and Cursor apps
Have it done
Security Fix $149 includes the bundle + history key scan, removes the key from your code, and gives exact rotation steps (you rotate the key; we tell you exactly which keys and settings).
FAQ
Is my anon key a problem?
No.
Does deleting the file fix it?
No. The key stays in your git history, in clones and forks, and in any copy already downloaded or built. Rotate it: once the old key is deleted (or, for a legacy service_role key, the legacy keys are deactivated), those copies are useless.
Can your free check find it?
The free check flags exposed secret keys found in the public homepage's scripts.