service_role key vs anon key
Supabase projects ship with two API keys. The anon (public) key is safe to use in browser/client code and is fully constrained by Row-Level Security policies. The service_role key bypasses RLS completely and must never reach the browser — it belongs only on a trusted server or in Edge Functions.
Also known as: Supabase API keys · anon key · service_role key
Both keys are signed JWTs that carry a role claim. The anon key's role makes every request subject to your RLS policies; the service_role key's role is granted BYPASSRLS, so it can read and write every row regardless of policy.
A common, serious mistake is shipping the service_role key in front-end code or committing it to a public repo — anyone who extracts it gets unrestricted read/write access to the entire database.
In Lovable apps this comes up whenever the AI builder needs to do something the anon key can't, such as writing across users or calling a privileged operation. The correct home for the service_role key is a Supabase Edge Function, not the browser. Common mistake: letting the assistant 'fix' a blocked write by reaching for the service_role key in client code instead of moving that logic server-side — which turns an RLS error into a full database exposure.
Related
Stuck on the thing this term describes? Talk to a senior engineer.
Book a free 30-minute audit call. We'll diagnose what's wrong and tell you exactly what it costs to fix.