Supabase anon key explained: public by design, safe only with RLS

Why seeing your anon key in the browser is normal — and when it becomes a breach.

If ShipLatch (or DevTools) shows your Supabase anon key in the frontend, that alone is not a vulnerability. Supabase documents the anon key as a public, low-privilege key. Authorization is enforced by RLS and your policies.

It is a problem when:

• RLS is disabled on a table with real data
• Policies use using (true) for sensitive reads
• You accidentally shipped the service_role key instead

UpGuard has written about systemic Supabase exposure at scale, including vibe-coded apps and agent-built projects (Everything Everywhere).

Keep the Supabase anon key in the client. Audit every table: RLS must be on, and policies must restrict rows with auth.uid(). Flag any service_role usage in the frontend as critical.

Related: Enable RLS · service_role

More guides

• Is my Lovable app secure?
• How to enable Supabase Row Level Security (RLS)
• Exposed Supabase service_role key: what to do now
• Lovable security checklist