What happens if my Supabase service key leaks?
The service_role key bypasses Row Level Security entirely. Whoever has it can read, change, and delete any row in any table, regardless of your policies. It is the most dangerous thing you can expose in a Supabase app.
If it leaks, for example it ended up in your frontend bundle instead of staying on the server, treat it as an emergency. Anyone who copied it has full access to your database until you act.
The fix has two parts, and both matter: remove the key from anywhere public, and rotate it in the Supabase dashboard so the leaked value stops working. Removing it alone is not enough, because the old value is already out.
Check whether a service key is in your live app
What it means
A password-like key that is supposed to stay private is sitting in your app where other people can find it. Anyone who copies it can act as you — run up bills, read your data, or send email in your name.
Why AI tools cause it
AI coding tools often paste an API key straight into a file to make something work, instead of hiding it in a private environment variable. It runs fine, so nothing warns you.
How xlogs checks it
xlogs scans your live JavaScript against 9 key formats covering Stripe, OpenAI, Anthropic, AWS, Google, GitHub, Slack, private key blocks, and Supabase service_role tokens.
How to fix it
The goal: The key is stored only in a server-side secret / environment variable, never in code or the client bundle, and the exposed value has been rotated (regenerated) because the old one is public.
- Move the key's value into a server-only environment variable
- Remove the literal value from the code and any client-side bundle (the affected spot)
- Make sure the .env file is in .gitignore
- Rotate (regenerate) the key at the provider — assume the old one is compromised
In my app (the spot the scan shows): a secret key is exposed. Please make this true: The key is stored only in a server-side secret / environment variable, never in code or the client bundle, and the exposed value has been rotated (regenerated) because the old one is public. Steps: Move the key's value into a server-only environment variable; Remove the literal value from the code and any client-side bundle (the spot the scan shows); Make sure the .env file is in .gitignore; Rotate (regenerate) the key at the provider — assume the old one is compromised. Then tell me exactly what you changed, and do not print any secret values back to me.
Then verify: After you deploy the fix, xlogs re-scans your live app and your files and confirms the key is no longer present.
Full step-by-step fix guide, with a copy-paste block for each AI tool →
Common questions
How would a service key even end up in my frontend?
Usually an AI tool or a copy-paste put it in a file that is part of the client build, to make a server-side call work quickly. It runs fine, so nothing warns you, and then it ships to every visitor. A scan of the live bundle catches it.