Skip to content

Scan rule · RSC-SEC-010

Supabase service_role key in the client

SecuritySeverity: HighCWE-798OWASP A07-2021

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

External scan (anonymous)

How to fix it

Rotate the key immediately, use it server-side only, and review access logs.

Scan your own app for free