Supabase October 30 grants checker

What the checker looks for

Missing grants

New tables in public with no grant to anon, authenticated or service_role. After October 30, supabase-js gets 42501 “permission denied” for these, including server code that uses the service_role key.

RLS off

Tables without row-level security. Reachable and unprotected is critical: every row is open to anyone the grant covers. Existing tables count as reachable, because the old defaults granted them.

RLS with no policy

Row-level security on but no policy, so the app silently gets an empty list.

Policies of true

using (true) or with check (true), including the “allow all for demo” policies AI builders often leave behind.

Grant all

GRANT ALL to browser roles, which includes truncate, references and trigger that no client needs.

Logged-out writes

Insert, update or delete granted to anon, which is anyone with your public key.

Sequences

Serial id columns whose sequence isn’t granted, so inserts fail with “permission denied for sequence”.

Views that skip RLS

Granted views without security_invoker, which show every row of the tables underneath, whatever their policies say.

Questions

What changes on October 30, 2026?

Supabase applies its “tables not exposed to the Data API by default” setting to all existing projects (projects created after May 30 already work this way). Tables you already have keep their grants. Tables and sequences created after that need an explicit GRANT before supabase-js, REST or GraphQL can reach them, for anon, authenticated and service_role alike; direct Postgres connections are not affected.

Is my SQL sent anywhere?

No. The check runs in your browser with JavaScript, and the SQL never leaves the page. Only an anonymous count of findings is recorded for usage statistics.

My existing tables show “relies on default grants”. Is that a problem?

Not today. Existing tables keep working after October 30. It means your migrations don’t write grants, so the next table you add the same way will fail. Add grants to the template your AI tool or team uses.

If the checker finds nothing, is my project secure?

Not necessarily. It reads the SQL text for common risky patterns. It can’t see changes made in the dashboard, what your functions do, storage buckets or how your app queries data. Supabase’s Security Advisor in the dashboard is the next place to look.

Why not just grant everything to authenticated?

A grant decides which operations reach the table; row-level security decides which rows. Grant only what the app does from the browser, keep RLS on, and write policies that compare the row owner with auth.uid().

Source: Supabase changelog: tables not exposed to the Data API automatically. Using Firebase instead? Try the Firebase Security Rules checker.