Supabase
The Supabase service role key: what it does, where to find it and what to do if it leaks.
The legacy Supabase service_role key is a server-side credential that bypasses row-level security. New projects use sb_secret_ keys for trusted backend work instead. Neither belongs in a browser. If one ships to the frontend, treat it as exposed and replace or migrate it before doing anything else.
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 credential exists for trusted backend work: background jobs, admin tools, webhooks and migrations that legitimately need to act across users' data. It bypasses RLS so those jobs are not constrained by end-user policies.
Use the public key under RLS whenever a task can be scoped to the current user. Reach for the service-role or secret key only when the work must cross those boundaries, and run it in server code, an edge function or another environment users cannot inspect.
Where to find it in Supabase
Open the project dashboard and go to Project Settings, then API Keys. Older projects show a legacy service_role JWT. Newer projects use secret keys beginning sb_secret_. The dashboard separates these from the publishable or anon key used by the browser.
If you cannot see a legacy service_role key, that does not mean the project lacks a backend credential. Supabase is retiring the legacy key format. Use a secret key for new server-side work and follow the migration guide before deactivating old credentials.
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. Replace a new secret key, or migrate away from a legacy service_role key that cannot be rotated independently.
What to do if a secret or service-role key leaked
For a new sb_secret_ key, create a replacement, update every trusted server that uses the old key, verify the new one works, then delete the exposed key. Search the deployed client bundle and repository history as well as the current source so you know how it escaped.
Legacy service_role keys cannot be rotated on their own. Migrate the project to the new publishable and secret keys, move each client and backend to the replacement, then deactivate the legacy keys. Do not assume changing a frontend environment variable revokes a credential that was already public.
Review logs and data access for the exposure window. This credential bypasses RLS, so the possible impact is not limited to the table or feature where you found it.
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.
- Where do I find the Supabase service role key?
- Open Project Settings and then API Keys in the Supabase dashboard. Older projects show a legacy service_role JWT. New projects use sb_secret_ keys for server-side work instead.
- How do I know if my service role key leaked?
- Check the deployed frontend bundle, client-side environment variables, repository history and public logs. If a service-role or secret credential appears in anything sent to a browser, treat it as exposed even if you do not see evidence that someone used it.
- Can I rotate a legacy service_role key?
- Not independently. Migrate to the new publishable and secret key system, move clients and backend jobs to the replacements, then deactivate the legacy keys. New sb_secret_ keys can be replaced individually.
- 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.