Is my Supabase anon/publishable key safe in the frontend?

The short answer

Yes, as long as RLS is doing its job. The publishable key (sb_publishable_...) and the legacy anon key are meant to live in browser and mobile code. Supabase lists the publishable key as "Safe to expose online" (Supabase: API keys).

No for the other kind. The secret key (sb_secret_...) and the legacy **service_role** key must never be in frontend code (Supabase: API keys).

Why

Anything shipped to a browser can be read. Supabase says keys in web pages and apps are public "because anyone can retrieve the key from the source code or build artifacts" (Supabase: API keys). So the publishable key isn't a secret. It just identifies your app. What protects your data is Row Level Security: requests with the publishable key run as anon (signed out) or authenticated (signed in), and your policies decide what those roles can reach (Supabase: API keys).

That's why the real checks are:

• RLS is on for every table in an exposed schema (Supabase: RLS).
• Policies only allow what each role should do (Supabase: RLS).
• The Security Advisor is clean, or you've reviewed every finding (Supabase: Advisors).

The secret key is different. It uses the service_role role, which bypasses RLS entirely, so "Policies never apply to a secret key" (Supabase: API keys).

Quick check

• Only sb_publishable_... (or the legacy anon key) is in client code.
• No sb_secret_... or service_role key is anywhere in the frontend or the repo. See how to check your bundle.
• RLS is on, with policies, for every exposed table (our RLS guide).

A scanner that flags your publishable key as a "leaked secret" is telling you about the scanner, not your app. See how we judge free scanners.

Note: Supabase is deprecating the legacy anon and service_role keys by the end of 2026 in favor of publishable and secret keys (Supabase: API keys).

Your turn

Before reading this, did you think the publishable key was a secret? Tell us. We're curious how common that is.