Supabase · Data API grants · Oct 30, 2026

Supabase “42501 permission denied for table”: fix it without turning RLS off

By Su, offensive security engineer (OSCP, CISSP) · Updated

Error 42501 “permission denied for table” means the database role your app uses (usually anon or authenticated) has no GRANT on that table. Supabase is changing its defaults so that new tables in the public schema are no longer exposed to the Data API automatically: new projects since May 30, 2026, and all existing projects on October 30, 2026. The safe fix is a least-privilege grant plus row level security (RLS). The unsafe fix, the one AI tools often suggest, is GRANT ALL to anon or switching RLS off.

Why the error appears

Supabase's Data API (the auto-generated REST and GraphQL layer) only works on tables the calling role is allowed to touch. Until now, every table you created in public was granted to anon, authenticated and service_role by default, so apps built by Lovable, Bolt or Cursor never needed an explicit GRANT. After the change, a new table needs an explicit grant before the API can see it. Without one you get:

code: 42501
message: permission denied for table orders

If your app talks to Postgres over a direct connection (an ORM or an app server with a connection string) this change does not affect it. It applies to the Data API. Read Supabase's announcement for exactly how your project is affected.

The safe fix: least-privilege grants, RLS on

Grant only the operations each role needs, keep row level security enabled, and write a policy so users reach only their own rows. Example for an orders table that belongs to signed-in users:

grant select, insert, update, delete on public.orders to authenticated;

alter table public.orders enable row level security;

create policy "users manage their own orders"
  on public.orders for all to authenticated
  using (user_id = (select auth.uid()))
  with check (user_id = (select auth.uid()));

Do not grant to anon unless the table is meant to be public. Do not run GRANT ALL. Do not “fix” the error by disabling RLS: the error goes away because the data is now open to everyone.

How to check your own project in 5 minutes

  1. List tables without RLS: select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;
  2. List who can do what: select grantee, table_name, privilege_type from information_schema.role_table_grants where table_schema = 'public' and grantee in ('anon','authenticated');
  3. Make explicit grants part of every migration that creates a table.
  4. Test it from two accounts: sign in as user B and try to read, update and delete user A's rows. Every attempt should fail.

Want it fixed and proven?

A Grants Fix ($149, 24 hours) diagnoses the 42501 errors, writes the least-privilege grant migration, keeps RLS on, and reruns the two-account test so you can see it works. The Launch Pass adds Stripe webhook and auth checks.

Questions

Is the Supabase October 30 grants change safe to ignore?

No, if your app uses the Data API (supabase-js, REST or GraphQL) and you create new tables. New tables need an explicit grant, and without it the app gets error 42501. Apps that only use a direct Postgres connection are not affected. Check Supabase's announcement for how your project is covered.

Should I fix 42501 by running GRANT ALL to anon?

No. That makes the error disappear by giving anyone with your public key access to the table. Grant only the operations each role needs, keep RLS on, and add a policy that limits users to their own rows.

How long does a Grants Fix take?

24 hours from signed authorization and staging access, for a fixed $149. You get a least-privilege grant migration and a two-account test showing user B cannot reach user A's data.

Request Grants Fix See pricing

Related