Guides

Supabase "42501 permission denied for table": fix it with a GRANT, not by turning off RLS

By Pritesh Ghodge, security engineer · Last updated 30 October 2026

If a feature that worked yesterday now fails with this, you're in the right place:

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

It's not a bug and nothing was hacked. Supabase changed a default, and on 30 October 2026 it reached existing projects. The fix is a few lines of SQL. The risk is that the quickest-looking fixes (turning off RLS, or granting everything to everyone) leave your data readable by anyone who visits your site.

What changed

Supabase's Data API (what supabase-js, /rest/v1/ and GraphQL use) can only reach a table if the Postgres role making the request has been granted access to it. Until now, every new table in the public schema got select, insert, update, delete for the anon, authenticated and service_role roles automatically. Now it doesn't:

• New tables in public need an explicit GRANT before the Data API can see them, however they were created: SQL editor, migrations, the CLI, MCP, or an AI builder like Lovable, Bolt or Cursor.
• Existing tables keep their current grants and keep working.
• RLS works exactly as before. Grants decide whether a role can touch the table at all; RLS policies decide which rows it sees.
• Not affected: the storage, auth and realtime schemas, and apps that only use a direct Postgres connection.

Supabase's reasoning is the same thing we see when scanning AI-built apps: agents and AI tools create tables with nobody reviewing the diff, and the old default exposed each one the moment it existed, before anyone had added RLS. Source: Supabase changelog: Tables not exposed to Data and GraphQL API automatically.

The two fixes not to use

1. Turning off RLS

It doesn't even fix the error: Postgres checks the grant first, so a missing grant fails with RLS on or off. But it's often what an AI assistant suggests when it sees "permission denied", and once someone also adds the grant, a table with RLS off is readable by anyone holding your anon key. That key is in your site's JavaScript by design.

2. Granting everything to everyone

-- Don't paste this to make the error go away
grant select, insert, update, delete on all tables in schema public to anon, authenticated, service_role;

This puts back the old behaviour for every table at once, including tables you meant to keep private (admin notes, internal logs, anything with emails). Each of them is then only as safe as its RLS policies. Supabase does document it, as the rollback for a project that opted in early and broke; it's not the fix for one missing table.

The safe fix: grant, enable RLS, add a policy, as one unit

Decide who actually needs the table. Logged-out visitors (anon) usually need little or nothing; signed-in users (authenticated) usually need their own rows.

-- 1. Grant only what each role needs
grant select, insert, update, delete on public.notes to authenticated;
grant select, insert, update, delete on public.notes to service_role;
-- (only if logged-out visitors must read it, e.g. a public catalogue)
-- grant select on public.notes to anon;

-- 2. Make sure RLS is on
alter table public.notes enable row level security;

-- 3. Say which rows each user may see and change
create policy "read own notes" on public.notes
  for select to authenticated using ((select auth.uid()) = user_id);
create policy "add own notes" on public.notes
  for insert to authenticated with check ((select auth.uid()) = user_id);

Replace notes and user_id with your table and its owner column. Add update/delete policies only if the app updates or deletes. If the error names a sequence rather than a table (older serial id columns), the role also needs grant usage, select on sequence public.notes_id_seq to authenticated;.

Put these statements in the same migration that creates the table, so the grant, RLS and policies always ship together.

A prompt for Lovable, Bolt or Cursor

AI builders tend to fix "permission denied" by widening access. Tell them what you want instead:

My Supabase query fails with 42501 "permission denied for table X".
Supabase no longer grants new public tables to API roles automatically.
Fix it safely:
1. Write a migration that grants only the privileges this app needs on X,
   per role (authenticated for signed-in features; anon only if logged-out
   visitors must read it - tell me why if you think they do).
2. Keep row level security enabled on X. Do not disable RLS.
3. Add policies so users can only read and change their own rows.
4. Do not grant on "all tables in schema public".
Show me the SQL before running it.

Supabase also says its agent skill includes the grants step, if your tool supports skills.

Check it worked, from the outside

Test as a stranger would, with only the anon key from your site:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/notes?select=*&limit=1" \
  -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY"

• 42501 → anon has no grant. Right, if logged-out visitors shouldn't use this table.
• [] → anon has a grant but RLS returns no rows. Also fine.
• Rows come back → anyone can read them. Fix the grant or the policy now.

Then do the two-account test: sign up as two users, create data as user A, and check user B can't see or change it. No outside scanner can do that one for you. To review every grant and policy at once, including INSERT and UPDATE checks a read test can't see, paste one query's output into the free Supabase RLS policy checker (runs in your browser). More on reading these results: how to check if your Supabase tables are readable by anyone.

Use the change to tidy up

The Table Editor shows a Data API exposure badge, and Security Advisor lists tables worth reviewing. If an older table doesn't need to be reachable from the browser at all, remove its API grants:

revoke all on table public.internal_logs from anon, authenticated;

Only do this for tables the frontend doesn't use, and test the app afterwards. Keep service_role if your edge functions or server use it.

Keep it that way

Every new table, view or quick fix from an AI edit is a chance for access to widen again. Abbi Labs checks your live app with the public key every visitor has, and Monitor re-scans weekly and after every deploy, emailing you only when something new appears.

Run a free scan

FAQ

Related guides

• Free tool: Supabase RLS policy checker
• How to check if your Supabase tables are readable by anyone
• Lovable app security checklist (from a security engineer)
• Supabase service_role key exposed? Do this in the next 15 minutes
• NEXT_PUBLIC_ and VITE_ variables are shipped to every visitor
• 3 files your production site shouldn't be serving: .env, .git and source maps
• Security headers for Lovable, Bolt, v0 and Cursor apps: CSP, HSTS and clickjacking