Supabase's October 30 change: what it fixes for your app's security, 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. (Supabase changelog)

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.

---

If you'd rather not do it by hand, LeakPatrol is a free read-only check for AI-built apps: leaked keys, public .env files and missing protections, with a plain-English fix and a copy-paste prompt for each.