DEV Community: Denys

Supabase anon key vs service role key: what each one opens

Denys Zaichenko — Mon, 02 Nov 2026 16:00:49 +0000

TL;DR. The anon key, now called the publishable key, is meant to be public. It maps to the anon or authenticated role, and your RLS policies decide what it sees. The service role key, now the secret key, maps to service_role, which bypasses RLS entirely. On my local test table with RLS on and no policy, the public key got 0 rows and the secret key got all 3. Put the publishable key in the browser, keep the secret key on a server, and rotate it if it ever shipped.

I'm Denys, a full-stack and AI engineer. A leaked secret key is the first thing I look for when I take over a Supabase app, because with it every other protection is decoration. This article explains what each key opens, with the requests I ran to check it.

What is the Supabase anon key?

The anon key identifies your app and not your user. Every request from a browser or a mobile app carries it, so it has to be public, and anyone can read it from the page source. A request with only this key runs as the Postgres role anon. When a user signs in through Supabase Auth, the same key travels with the user's token and the request runs as authenticated. Your RLS policies are written for those two roles.

Supabase is renaming the keys. The API keys guide calls the new ones publishable (sb_publishable_…) and secret (sb_secret_…), and deprecates the legacy JWT-based anon and service_role keys by the end of 2026. The roles behind them stay the same.

Key	Legacy name	Postgres role	RLS applies?	Where it goes
Publishable `sb_publishable_…`	`anon` key	`anon`, or `authenticated` with a user token	Yes	Browser, mobile app, anything you ship
Secret `sb_secret_…`	`service_role` key	`service_role`	No, the role has `BYPASSRLS`	Server, Edge Function, cron job only

Is it safe to expose the Supabase anon key?

Yes, if every table, view and function it can reach is protected. The key itself grants nothing special, and the grants and policies on your schema decide everything. I checked this on a local Supabase stack (CLI 2.109.1, Postgres 17.6) with one table of three fake orders.

Figure 1. From the Supabase API keys guide, checked on a local stack, 23 October 2026.

Table state	Publishable key	Secret key
RLS off	All 3 rows, and an insert returned `201 Created`	All 3 rows
RLS on, no policy	`[]`	All 3 rows
RLS on, policy `using (true)`	All 3 rows	All 3 rows
No grant for `anon`	`42501 permission denied`, with a hint naming the missing `GRANT`	All 3 rows

So the publishable key is exactly as safe as your weakest table. A table without RLS, or with a policy that allows every row, is readable by anyone who opens DevTools. That's the hole behind CVE-2025-48757, where 170 of 1,645 Lovable showcase apps served data to the public key.

What is the service role key, and why is it dangerous?

The secret key is the master key. It runs as service_role, which has the BYPASSRLS attribute, so no policy you write ever applies to it. In the last column of the table above, it read all three rows in every state. Supabase's guide lists where it belongs: servers that run their own authorization checks, Edge Functions, background jobs and admin tools. Two details from the guide matter in practice:

The new secret key refuses browser requests. Supabase matches the User-Agent and returns 401. The legacy service_role JWT has no such check, so a leaked legacy key works from anywhere. My local stack, which has no such gateway check, answered a script with the secret key with all 3 rows.
A secret key bypasses RLS only when the request carries no user token. With a signed-in user's token, the request runs under that user's policies.

An Edge Function that uses the secret key has to check who is calling and filter by owner or company itself, because nothing below it will.

Where do you find the keys?

In the Dashboard, open your project's Connect dialog for the URL and publishable key, or Settings → API Keys for every key, legacy ones included. Locally, supabase start and supabase status print a publishable key and a secret key. Keep them in environment variables. In Next.js, only the publishable key may carry the NEXT_PUBLIC_ prefix, because the bundler ships anything with that prefix to the browser.

What do you do if the service role key leaked?

Treat it as compromised, because every row in every table was readable and writable by whoever found it.

Create a new secret key, move your servers to it, then delete the leaked one. If the leak was a legacy service_role key, the way out is the move to the new keys. Create a publishable and a secret key, switch the app, then disable the legacy keys in Settings → API Keys, where they otherwise stay valid.
Search the built JavaScript and the Git history for sb_secret_ and service_role. Escape's scan of 5,600 vibe-coded apps found 400+ exposed secrets, most of them in frontend bundles.
Review what changed while it was out: new users, role changes, deleted rows.

A scanner on the database side can catch the same problem from the other direction: roles that bypass RLS, tables with RLS off, policies that allow every row and columns that look sensitive and are readable by anonymous visitors. To check what your public key reaches in practice, the steps are in vibe coding security risks.

Originally published at madsalt.tech. Written with AI assistance, checked by me.

Supabase exposed schemas: what the list opens up

Denys Zaichenko — Wed, 28 Oct 2026 14:00:50 +0000

TL;DR. The Exposed schemas list in Supabase decides which schemas the Data API serves to anyone holding your public key. The default is public and graphql_public. Every table, view and function in a schema on that list needs its own grants and RLS, so each extra schema is more surface to defend. Keep the list short and check it first.

I built a free Supabase security checker and the Exposed schemas list is one of the first things it reads. When someone asks me how secure their Supabase project is, this setting is where I start.

What does "exposed" mean in Supabase?

Supabase serves your database over REST with PostgREST. PostgREST only answers for the schemas in its db_schema list. You edit it in the Dashboard under Project Settings → Data API → Exposed schemas. On the project config I looked at, the value was public,graphql_public, and the Supabase custom schemas guide says public is exposed by default. A request for a schema outside the list gets refused. PostgREST also never allows pg_catalog or information_schema in it.

Why does the list matter?

Everything inside an exposed schema can be reached with the public key. Tables, views and functions. Supabase's RLS guide is blunt about it. A table in an exposed schema without RLS can be read and written by any role that has a grant on it. A schema that's not on the list can't be reached through the API at all.

So an extra schema is not a neutral change. Add storage or vault to the list and you've put internal tables within reach of the Data API. Add your own schema and every table in it needs the same care as public.

From my Supabase security rules and the Supabase Data API docs, 22 October 2026.

Which extra schemas are the worst?

An internal Supabase schema in the list (auth, storage, realtime, vault, extensions and similar) is a high severity problem when I review a project. A custom schema like api is a medium one, a warning. The same list also decides where other problems count: tables with RLS off, anon write grants, always-true policies, views without security_invoker and SECURITY DEFINER functions that anon can call only matter in exposed schemas, because that's where the public key reaches them.

How do you use a custom schema safely?

A custom schema is a legitimate pattern. Supabase's Securing your API guide describes a dedicated schema such as api as a way to make the exposed surface easier to identify and audit, with internal tables kept in schemas that aren't exposed. Two steps make it work, and the custom schemas guide gives both. Add the schema to Exposed schemas, then grant usage on it to anon, authenticated and service_role, plus privileges on its objects.

The guide's example grants ALL on every table. I wouldn't copy that line as it stands. The Securing your API guide says to give each role the minimum it needs, and to enable RLS on every table you expose. Grants decide if a role can touch a table at all, and policies decide which rows.

There's one separate change. Supabase stops granting new public tables to the Data API automatically. It became the default for new projects from 30 May 2026 and will be applied to existing projects on 30 October 2026, and existing tables keep their grants. That is the grants layer. It doesn't change which schemas are on the list.

How do you check your own project?

Open Project Settings → Data API and read Exposed schemas. If it's more than public and graphql_public, ask what each extra schema is for.

Then list the tables in those schemas that have RLS off, and see if anon can already read them:

select n.nspname as schema,
       c.relname as "table",
       has_table_privilege('anon', c.oid, 'select') as anon_can_select
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname in ('public', 'api')  -- your Exposed schemas
  and c.relkind in ('r', 'p')
  and not c.relrowsecurity
order by 1, 2;

I ran it on a throwaway Postgres 17 with an api schema holding one table with RLS and one without, plus a public table without RLS. It returned only the two without:

 schema | table  | anon_can_select
--------+--------+-----------------
 api    | orders | t
 public | logs   | t

Every row with anon_can_select true is a table anyone with your public key can read, until you enable RLS or revoke the grant. The query covers tables only. Views and functions need their own look, and my Lovable app security checklist walks through them. How I test Supabase RLS shows how to prove the policies work.

Originally published at madsalt.tech. Written with AI assistance, checked by me.

Supabase 42501 permission denied is a grant problem, not RLS

Denys Zaichenko — Mon, 26 Oct 2026 12:08:12 +0000

TL;DR. 42501 permission denied for table … means the role has no grant on the table. Postgres stops the request before any RLS policy even runs. From 30 October 2026 Supabase stops granting new tables in public automatically on existing projects, so every table you create after that answers 42501 until you grant it. The fix is three statements together - a grant, enable row level security and a policy. Grant alone without RLS and the table is open to everyone.

I built a free Supabase security checker that reads the grants on every exposed table. Most projects have too many grants. 42501 is the other side, too few. So I reproduced it locally to see what really happens.

What does 42501 mean?

It's the Postgres code for insufficient privilege. Before a client touches a table Postgres checks two layers. Grants decide if the role can run the operation at all. RLS policies decide which rows it sees. A missing grant fails first and loud, as an error. A policy that matches nothing fails quietly, you just get an empty list. So if you see 42501, look at grants and leave your policies alone for now.

PostgREST (the Data API behind supabase-js) passes the error through with a hint. On my local stack (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) a request with the publishable key to a table with no grant for anon came back as HTTP 401 with this:

{
  "code": "42501",
  "details": null,
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.orders TO anon;",
  "message": "permission denied for table orders"
}

Why do new tables throw 42501 after 30 October 2026?

Until now every new table in public got select, insert, update and delete for anon, authenticated and service_role through default privileges. So it was reachable over the Data API the second you created it, protected or not. Supabase removes those defaults. Optional from 28 April 2026, default for new projects from 30 May 2026, and on 30 October 2026 it hits all existing projects. Tables you already have keep their grants.

I ran the same two alter default privileges … revoke statements from the changelog on my local project and then created a new table invoices.

My reproduction on a local Supabase stack with the default privileges from the Supabase changelog, 23 October 2026.

Request to the new table	Result
Publishable key, no grant	HTTP 401, 42501, hint `GRANT SELECT ON public.invoices TO anon;`
Secret key, no grant	HTTP 403, 42501, hint `… TO service_role;`
Publishable key, after `grant select` and `enable row level security`	HTTP 200, `[]` until a policy allows rows

Two things surprised me. The secret key gets refused too. service_role skips RLS but it still needs a grant, so an Edge Function or a server job writing to a new table breaks exactly the same way. And the revoke only takes back those four operations. The new table still came with REFERENCES, TRIGGER and TRUNCATE for anon, authenticated and service_role. No policy applies to TRUNCATE.

How do you fix it without opening the table?

Grant, RLS and policy are one change. Put them in one migration and give each role only what it needs.

revoke all on table public.invoices from anon, authenticated;
grant select, insert, update on table public.invoices to authenticated;
grant select, insert, update, delete on table public.invoices to service_role;

alter table public.invoices enable row level security;

create policy "Owners read their invoices"
on public.invoices for select
to authenticated
using ((select auth.uid()) = user_id);

The revoke all at the top clears the TRUNCATE, TRIGGER and REFERENCES that came with the table. Please don't answer 42501 with grant all on all tables in schema public to anon. That brings the old default back for every table at once, and any table without RLS becomes readable by anyone who has your public key.

If an AI tool creates your tables, tell it to write grants, RLS and policies in the same migration. The hint in the error is written so an agent can fix the grant by itself, but it only names the grant. It says nothing about the RLS that should come with it.

What to check in your own project

Look for three things in the grants layer. Default privileges that still grant new tables to the API automatically. Write grants for anon that no policy uses. And TRUNCATE, TRIGGER and REFERENCES on tables for authenticated, like the ones above. Why RLS still matters after the grant is in how to test Supabase RLS, and how grants and policies look across a whole app is in my Lovable app security checklist.

Originally published at madsalt.tech. Written with AI assistance, checked by me.