Supabase service_role key leaked: what to do
This key ignores all your security rules. It is the most serious key in the Supabase stack.
1. Rotate it now
Revoke and reissue in the Supabase dashboard
- 1Open your project → Settings → API.
- 2Find the service_role key and reset it. The old value stops working immediately.
- 3Update every server function and backend environment variable that used it.
- 4Redeploy anything that holds it, then confirm those services still work.
Console: https://supabase.com/dashboard/project/_/settings/api
2. What someone can do with it
- Read every row of every table, for every user, ignoring all Row Level Security policies — this key exists specifically to bypass them.
- Modify or delete any record, including auth records.
- Read and write your storage buckets regardless of their policies.
- In short: whoever has it has your entire database.
3. Check whether it was already used
Look for activity you did not cause
- 1Open your project → Logs → API and filter the period since exposure.
- 2Look for requests whose IP is not your server, especially bulk SELECT queries against user tables.
- 3Check Auth → Users for accounts you did not create, particularly ones with elevated roles.
- 4Look for rows in your tables that you cannot account for, and for unexpected deletions.
4. Find out how it leaked
The usual cause is naming it with a client-exposed prefix — VITE_SUPABASE_SERVICE_ROLE_KEY or NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY — which compiles it straight into the browser bundle. The second most common cause is an AI tool reaching for the service_role key to make a query 'just work' when RLS was blocking it.
Find every hardcoded credential in this project and move it out of the code. 1. Search all files — including client code, config files, and anything already committed — for hardcoded secrets: Supabase keys, plus any string starting sk-, sk_live_, AKIA, ghp_, or variables named *_SECRET, *_TOKEN, *_API_KEY. 2. For each one, tell me the file, the line, and whether that code runs in the browser or on the server. 3. Move every real secret to a server-only environment variable. Do NOT use a client-exposed prefix (VITE_, NEXT_PUBLIC_, REACT_APP_) — those are compiled into the browser bundle. 4. Any provider call that needs the secret must happen server-side; change the frontend to call my own endpoint instead of the provider directly. 5. Check whether the secret is in git history, not just the current files. If it is, say so — removing it from HEAD does not remove it from history. Give me a list of every secret found, where it was, and what you changed.
This is one check out of 40+
Paste your site address and we run the whole list from the outside — leaked keys, open databases, unprotected pages — then hand you one prompt that fixes what we find. Free, about 30 seconds, no signup.
Check my site — free