The Supabase `service_role` key bypasses all RLS. If it appears in frontend code, any user can extract it and access your entire database.
By Contributor · published 5/30/2026
Supabase provides two API keys per project: the `anon` (public) key, which respects RLS policies, and the `service_role` key, which bypasses all RLS entirely. The service role key is designed for server-side admin operations only.
When AI tools generate code, they sometimes use the service role key in configurations or client initialization — especially when debugging a situation where the anon key “wasn’t working.” The result: if that key appears anywhere in client-side JavaScript, it is extractable by any user who opens browser developer tools.
Per [ModernPentest’s documented Supabase misconfigurations](https://modernpentest.com/blog/supabase-security-misconfigurations): “The `service_role` key bypasses all RLS policies and should NEVER be exposed to the client.”
**How to check:** Search your codebase for the string `service_role` or your actual service role key value. It should appear only in server-side files (API routes, Edge Functions) and never in any file that starts with `VITE_`, `NEXT_PUBLIC_`, or any other client-exposed prefix.
**Correct pattern:**
```jsx
// Client-side: use anon key (respects RLS)
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
);
// Server-side only: use service role (bypasses RLS, admin operations)
const supabaseAdmin = createClient(
process.env.SUPABASE_URL,
process.env.SUPABASE_SERVICE_ROLE_KEY // never NEXT_PUBLIC_ prefix
);
```
## Why it matters
Exposing the service role key is equivalent to giving every user admin access to your database. No RLS policy, no authentication check, no restriction applies.
## Suggested next action
Search your entire codebase for `service_role`. Confirm it never appears in any file accessible to the client.
