LeakPatrolSupabase's October 30 change: what it fixes, and what it doesn't
On 30 October 2026, Supabase changes how new tables are exposed in existing projects. It's a good security change, but it's easy to misread as "my database is now safe". It isn't: tables you already have keep exactly the access they have today.
What's changing
Until now, every table created in the public schema was automatically granted to the anon, authenticated and service_role roles, so the Data API (REST and GraphQL, which supabase-js uses) could read and write it straight away. Row Level Security was the only thing standing in the way.
From 30 October, new tables in public won't get those grants automatically. You have to opt each one in with a Postgres GRANT before your app can reach it through the Data API. New projects have worked this way since May, and the Supabase CLI switched for local development in June.
What doesn't change
- Existing tables keep their grants. If a table is readable by anyone today, it still will be on 31 October.
- Row Level Security works the same. A table with RLS off, or with a
using (true)policy, is just as open as before. - Direct database connections (an ORM or server using a connection string) aren't affected.
So the change stops new accidents. It doesn't fix the leaks that are already out there.
What might break
If your app (or your AI tool) creates new tables after 30 October through migrations or the SQL editor, those tables won't be reachable from the browser until you grant access. Expect a permission error from the Data API on a brand-new table.
The fix is to grant only what the app needs, and to switch RLS on at the same time:
alter table public.notes enable row level security;
grant select, insert, update, delete on public.notes to authenticated;
create policy "Users manage their own notes"
on public.notes for all
using (auth.uid() = user_id)
with check (auth.uid() = user_id);Only grant to anon (logged-out visitors) if the table is meant to be public, like a product list, and then usually just select.
Watch out for AI tools "fixing" the error the wrong way. If you paste a permission error into Lovable, Bolt or Cursor, check it doesn't respond by granting everything to anon or turning RLS off. That would recreate exactly the problem this change is meant to prevent.
What to check before 30 October
Because existing tables keep their access, this is a good moment to audit them. In the SQL editor:
1. Which tables have RLS off:
select tablename, rowsecurity
from pg_tables
where schemaname = 'public';2. What logged-out visitors are allowed to do:
select table_name, string_agg(privilege_type, ', ') as privileges
from information_schema.role_table_grants
where grantee = 'anon' and table_schema = 'public'
group by table_name;Any table that appears in the second list with RLS off in the first is readable (and often writable) by anyone who has your anon key, which is in your app's JavaScript.
3. Policies that let everyone through: look for using (true) in Authentication → Policies.
LeakPatrol's free scan checks your live app from the outside for leaked keys, public files and missing protections. The full report adds a Supabase check that reads your table, policy, view and storage settings from a query you run yourself, so we never need access to your project.
Check your app in a minute
Free, read-only, no sign-up. Every problem comes with a plain-English fix and a prompt for your AI tool.
Get the 10-point checklist
Every check we run on AI-built apps, with how to do each one yourself. Straight to your inbox.
Plus an email when automatic re-checks launch, and the odd tip. Unsubscribe any time.
Questions
What changes in Supabase on October 30, 2026?
New tables created in the public schema of existing projects are no longer automatically granted to the anon, authenticated and service_role roles, so they are not reachable through the Data API until you add an explicit GRANT.
Does the Supabase October 30 change secure my existing tables?
No. Existing tables keep their current grants and Row Level Security behaves the same, so tables that are open today stay open. You need to check RLS and grants on existing tables yourself.
Why does my new Supabase table give a permission error?
After the change, new public tables need an explicit grant, for example grant select, insert, update, delete on public.my_table to authenticated, together with Row Level Security policies.