Supabase anon key exposed: what it actually means

The four Supabase key types

• Publishable key (sb_publishable_...): low privilege, documented as safe to expose in web pages and apps.
• anon (a long-lived JWT starting with eyJ): the legacy version of the publishable key.
• Secret key (sb_secret_...): elevated; bypasses RLS. Backend only.
• service_role (JWT): legacy version of the secret key. Also bypasses RLS.

Supabase says it is deprecating the legacy anon and service_role keys by the end of 2026 in favor of publishable/secret keys. Source: Supabase docs: API keys.

What an exposed anon key can do

Requests with the publishable/anon key run as the Postgres role anon (or authenticated once a user signs in). Postgres checks table grants first, then RLS policies.

Supabase's docs warn that a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and that on existing projects new tables in public start with select/insert/update/delete granted to anon. Adding policies does not remove those grants. Source: Supabase docs: Row Level Security.

When to worry

1. Any table in public with RLS disabled.
2. Policies to anon using (true) on data that is not meant to be public.
3. Views over protected tables (views bypass RLS by default unless created with security_invoker = true on Postgres 15+).
4. A service_role or sb_secret_ key anywhere in the frontend — that is a real leak. See what to do.

What to do

1. Check which tables have RLS enabled.
2. Revoke grants the anon role should not have, then write one policy per operation.
3. Run a free, permission-gated RLS Radar scan of your own app.

FAQ

Should I hide my Supabase anon key?

No. It is designed to be public; anyone can read it from your shipped code. Protect data with grants and RLS instead.

Can someone delete my data with the anon key?

Only if grants and RLS allow it. Tables without RLS that keep the default anon grants can be written to, so enable RLS and revoke unneeded grants.