Scan rule · RSC-SEC-010
Supabase service_role key in the client
Decodes JWTs in the bundle and reports the `service_role` claim, which bypasses RLS entirely.
Why this matters
Supabase gives you two keys. The anon key may go into the frontend — it only sees what your Row Level Security rules allow. The service role key is the master key: it bypasses every RLS rule and may read, change and delete any row. It belongs on the server only.
The typical path to a leak: a generator or tutorial puts the key into a variable prefixed NEXT_PUBLIC_ (Next.js) or VITE_ (Vite). Both get compiled straight into the bundle every visitor downloads. Anyone who opens the dev tools has the master key — and with it the entire database, no matter how secure the login looks.
How to check it yourself: open your site and search the served JavaScript for “service_role”. If you find something, the key is public. Hiding it does not help at that point — it has to be rotated in the Supabase console and afterwards used exclusively server-side (API route, server action, edge function).
Scan tier
How to fix it
Rotate the key immediately, use it server-side only, and review access logs.