Supabase Service-Role Key Exposed? Here's Exactly What to Do

Found your Supabase service_role key in client code or a public repo? It bypasses all your security. Here's exactly how to rotate it and lock things down — step by step.

Aug 7, 2026 · 5 min read

If your Supabase service_role key has leaked, don't panic — but do move now. Unlike the anon key, the service-role key bypasses every Row-Level Security policy you have. Anyone holding it can read, edit, and delete your entire database. Treat an exposed service-role key as a live break-in.

If you only do one thing

Rotate the key immediately. Everything else below matters, but rotation is what actually cuts off the attacker — the leaked value is out there and can't be un-leaked.

Step 1 — Rotate the key now

In your Supabase dashboard, open Project Settings → API and roll (regenerate) your keys. Rolling invalidates the leaked service-role key so it stops working.

Rolling the underlying JWT secret also rotates your anon key, so update the keys in every environment afterward (Vercel/Netlify env vars, local .env, edge functions).
Redeploy so your app picks up the new values.

Step 2 — Get it out of the code (and history)

Delete the key from your source. It should never live in client-side code at all.
If it was in a public repo, assume bots already scraped it — Step 1 (rotation) is what protects you, not deletion. Then purge it from git history (e.g. git filter-repo or BFG) so it isn't sitting in old commits.

Step 3 — Turn on Row-Level Security for every table

The service-role key is powerful precisely because your anon /authenticated access is supposed to be constrained by RLS. If RLS is off, even your public anon key exposes everything. In the Table Editor, enable RLS on every table and add policies so users can only touch their own rows.

Step 4 — Keep the service-role key server-side, forever

Client code gets the anon key only. Never the service-role key, and never behind a NEXT_PUBLIC_ variable (that ships it to the browser).
Use the service-role key only in trusted server contexts: server actions, route handlers, or Supabase Edge Functions.

Check your repo for exposed Supabase keys — free

Trust detects service-role JWTs and 20+ other key types in your code and live site.

Run a free scan →

Want to be sure nothing else slipped through? Trust scans your GitHub repo and your live URL in one pass and flags exposed keys, RLS-off patterns, and misconfigurations — in plain language, with the fix.