Auth and database

Keep the service_role key on the server

The Supabase service_role key and new sb_secret_ keys bypass RLS. Where they may be used, and what to do if one leaked.

Why it matters

The service_role key, and the newer sb_secret_ secret keys, bypass Row Level Security entirely. Anyone holding one has full access to your database through the API.

How to fix it

1. Use it only in API routes, server actions, edge functions or background jobs.
2. Never put it in a NEXT_PUBLIC_ or VITE_ variable, client components or a mobile app.
3. For user requests, prefer a client that uses the user's session so RLS still applies.
4. If it was ever exposed, rotate it in the Supabase dashboard (API keys settings) and redeploy.

How to verify

• Search your built frontend for service_role and sb_secret_, or use the key scan.
• Decode any JWT found in the bundle; its role should be anon.

Questions

How do I tell the anon key from the service_role key?

Both legacy keys are JWTs. Decode the middle part: the role claim says anon or service_role.

Related checks

• Enable Supabase RLS on every table
• No secret keys in the browser bundle
• Rotate leaked keys, don't just delete them

Tick it off in the full checklist