Home / RLS / Is the anon key safe to expose?

Supabase RLS - Fundamentals

Is the Supabase anon key safe to expose?

01 Short answer

Yes. The anon key (and the newer sb_publishable_... key) is public by design - Supabase expects it in your frontend bundle, and anyone can read it from your site's JavaScript. That by itself is not a vulnerability.

The catch: the anon key is only safe because Row Level Security is supposed to stand between it and your data. If RLS is off on a table the key can reach, that public key reads every row in it (and writes too, if the table also grants insert/update/delete to anon). So the honest answer is "yes, if RLS is on everywhere it can reach" - not "yes, always."

02 Why it's safe when RLS is on

The anon key only tells Supabase which role the request runs as (anon, the signed-out visitor). What that role can actually see is decided by RLS. Proven on Postgres:

what anon sees, by configuration

-- RLS OFF, anon has a grant:        anon reads EVERY row  (leak)
-- RLS ON, no policy:                anon reads 0 rows    (deny by default)
-- RLS ON, policy for authenticated: anon reads 0 rows    (policy doesn't match anon)
-- RLS ON, policy scoped to the user: each user reads only their own rows

So with RLS on and a correct policy, the public key is exactly as powerful as you decide - usually "read the public catalog, nothing private." That's why Supabase ships it to the browser without worry.

03 Where the real danger is

Note the Oct 30, 2026 platform change doesn't fix this: new tables stop being auto-exposed, but a table that already has RLS off stays open. What changes on Oct 30.

04 Check your own app in two ways

In the SQL editor, list every table and view and whether anon can read it with RLS off:

check.sql

select c.relname,
       has_any_column_privilege('anon', c.oid, 'select') as anon_can_read,
       c.relrowsecurity                                 as rls_on
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p', 'v', 'm')
order by 1;

Any row with anon_can_read = true and rls_on = false is open to the public key. From outside, the free scanner checks this from outside against your live app - a leaked service_role key, and tables anyone can read without logging in - using only the public key your app already ships, and reading only row counts, never your data.

05 Turn an open table safe

Enable RLS and add a policy that scopes rows to the signed-in user, in the same migration:

migration.sql

alter table public.notes enable row level security;

create policy "owner reads own" on public.notes for select to authenticated
  using (user_id = (select auth.uid()));

Signed-out visitors (anon) now read nothing from notes; signed-in users read only their own rows. The anon key is still in your bundle - and now it's genuinely safe. Full set: owner-scoped policy for all four operations.

FAQ