eyJ… (JWT)
Exposed Supabase Service-Role Key? Here's how to detect and rotate it
The service_role JWT (eyJ…) bypasses Row-Level Security and owns your whole DB. Scan free with Trust, then replace it with a new secret key in Settings.
The Supabase service_role key is a JWT (starts with eyJ) that BYPASSES Row-Level Security — full read/write to every table, ignoring all your RLS policies. It's meant to live only on your server. If it leaks, an attacker effectively has admin on your database.
What an attacker can do with a leaked Supabase Service-Role Key
- Reads and dumps every row in every table — all user data, regardless of RLS.
- Inserts, updates, or deletes any data, including wiping or ransoming your database.
- Calls privileged RPCs, storage, and auth-admin endpoints as a superuser.
- Uses full DB access to escalate — reset users, forge records, exfiltrate secrets stored in tables.
How Supabase Service-Role Keys get exposed
- Placed in a NEXT_PUBLIC_ / VITE_ env var so it ships in the client bundle — never do this; it's server-side only.
- Committed to a repo, or hardcoded in an edge function, script, or Dockerfile that got shared.
- Confused with the anon key and shipped to the browser.
- Exposed in server logs, error trackers, or a screenshot.
Scan your repo and live site for exposed Supabase Service-Role Keys — free
Trust checks your code, git history, and shipped JavaScript. No signup, results in about a minute.
Run a free scan →How to rotate a leaked Supabase Service-Role Key
- Open your project's Dashboard → Settings → API Keys.
- Click Create new secret key to generate a modern sb_secret_… key (Supabase now recommends replacing the legacy service_role JWT rather than rotating it in place).
- Swap the leaked key for the new secret key in your server env/secrets, then deploy.
- Once nothing uses the old key, disable/delete the legacy service_role key from the same page.
- Only if you must invalidate the JWT itself: rotating the project's JWT secret invalidates ALL legacy keys and signs out every user — plan for that downtime.
- Audit your database and logs for unauthorized changes made while the key was exposed.