Supabase
The Supabase service role key: powerful, secret, server-side only.
The Supabase service role key bypasses row-level security completely. It can read and write every row in every table, no matter what your policies say. That makes it essential for trusted server work and catastrophic if it ever ships to the browser. It belongs on the server, always.
One leaked service role key voids every policy you wrote.
You can enable row-level security on every table and write perfect policies, and it all counts for nothing if the service role key reaches the front end. That key is built to ignore RLS so your backend can do admin work. In a browser, that same power is handed to every visitor, who can then read and write your entire database directly. It is one of the most serious mistakes a Supabase app can make.
What the service role key is for
The service role key exists for trusted server-side work: background jobs, admin tools, webhooks, migrations, anything that legitimately needs to act across all users' data without being limited by row-level security. Because it bypasses RLS, it must only ever run somewhere your users cannot see: server code, edge functions, a backend environment variable.
If a task can be done with the anon key under RLS, use the anon key. Reach for the service role key only when the work genuinely needs to cross the boundaries RLS enforces, and keep that work on the server.
Where it must never appear
Never put the service role key in front-end code, in a client-side environment variable that gets bundled, in a mobile app, in a public repository, or anywhere a browser can reach it. A common trap is a build-time environment variable that looks server-side but gets inlined into the client bundle. If your framework exposes variables prefixed a certain way to the browser, the service role key must not use that prefix.
Another trap is convenience during development: wiring the service role key into the client to make something work quickly, meaning to fix it later, and shipping it. Once it is in a deployed bundle, treat it as public and rotate it.
What to do if it leaked
Rotate it immediately from the Supabase dashboard. A rotated key makes the exposed one useless. Then find every place the old key was used on your server and update them, and audit what the exposed key could have touched while it was out, which for the service role key is everything.
After rotating, move the key to a proper server-side secret and confirm it is no longer in any client bundle. Then verify your row-level security is actually doing its job, because teams that leaked the service role key often leaned on it precisely because their RLS policies were incomplete.
Common questions.
- Can I use the service role key to make development easier?
- Only on the server. It is genuinely useful for trusted backend work. The danger is using it in client code to bypass a policy that is inconvenient, because that ships unlimited database access to every visitor. If a policy is in your way, fix the policy.
- How do I know if my service role key leaked?
- Check whether it appears in your deployed front-end bundle, your client environment variables, your git history or any public repo. If you are unsure, rotate it as a precaution; rotation is cheap and instantly invalidates any exposed copy.
- Can you check my key handling?
- Yes. Our Supabase security audit confirms the service role key stays server-side, checks the anon key's exposure under RLS, and reviews any functions that bypass policies.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.