Service Role Key (Supabase)
The service role key is Supabase's master key: it bypasses every Row Level Security rule and may read, change, and delete any row. It belongs on the server only. If it ends up in frontend code, a NEXT_PUBLIC variable, or the browser bundle, any visitor can read and overwrite the entire database — no matter how well the rest of the app is secured.
Supabase gives you two keys: the anon key (public, bound to RLS) and the service role key (private, RLS-free). The anon key may go into the frontend — it only sees what your RLS policies allow. The service role key never may, because it overrides every rule. This distinction is the single most common critical mistake in AI- and no-code-generated apps.
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 shipped browser bundle. Anyone who opens the page and looks at the dev tools has the master key. From then on the database is open, no matter how strong the password is.
Check it yourself: the service role key belongs only in server-side code (API routes, server actions, edge functions) and in environment variables without a NEXT_PUBLIC/VITE prefix. Search the entire frontend bundle for “service_role”. That is exactly the finding our Rescue deep scan surfaces — one of the results that puts an app straight onto “stop”.