Service Role Key in Frontend Code in Supabase
Supabase security checks · CRITICAL
Your service role key is in frontend code. Anyone with it skips every policy.
What goes wrong
The Supabase service_role key has the BYPASSRLS privilege, so it ignores every row level security (RLS) policy. If it is in client-side code, an attacker can copy it and get unrestricted access to your database, the same as a superuser.
How it happens
The key is put in an env var with a public prefix, such as NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY, or hardcoded. AI code generators often do this because they mix up the anon and service_role keys.
How to find it
Search your JS bundles for JWTs starting with eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9, decode them and check whether the role claim is service_role. Also grep for env var names containing SERVICE_ROLE with a public prefix (NEXT_PUBLIC_, VITE_, REACT_APP_, EXPO_PUBLIC_).
How to fix it
Remove the key from all frontend code and use it only on the server (Next.js Server Components, API Routes, Edge Functions). Import the 'server-only' guard in admin client files. If the key was exposed, rotate it in Dashboard → Settings → API.
Check your own project
Locksoup runs these checks on your Supabase database in about a minute, with a read-only role, and gives you the SQL to fix what it finds.