Exposed Supabase service_role key: why it's critical and how to find it
Of all the ways an AI-built app can leak, an exposed Supabase service_role key is the most dangerous — and one of the most common. It is a full-admin key that ignores every Row-Level Security policy. If it's in your front-end, your entire database is effectively public.
What the service_role key actually does
Supabase gives you two keys: the anon key (public, constrained by RLS) and the service_role key (admin, bypasses RLS entirely). The service_role key is meant for trusted server environments only. In the browser, it's a master key to all your data.
Why AI builders leak it
To make a feature 'just work', generated code sometimes uses the service_role key client-side instead of wiring a proper server route. It ends up in the JavaScript bundle, where anyone can read it from the network tab.
How to check if yours is exposed
Look in your deployed front-end bundle and network calls for a key labelled service_role, or any Supabase key with admin scope. The fastest way: paste your app's URL into Opviva's free scanner, which inspects the live bundle for it — no code access needed.
How to fix it
1) Rotate the key immediately in your Supabase dashboard. 2) Remove it from all client code; route admin actions through a server endpoint that holds the key in an environment variable. 3) Enable Row-Level Security on every table so the anon key alone is safe. Opviva can prove the leak is real by pulling the key straight from your live bundle, then open a reviewed pull request that does steps 2 and 3 for you — and keep watching so it doesn't come back.