Free toolSupabase grants and RLS 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

Did the October 30 change break my app?

Not on the day itself. Supabase says existing tables keep their current grants, so what worked before keeps working. The risk is the next table you create: without a grant, every request to it from supabase-js, REST or GraphQL fails with “permission denied for table” (error 42501). Paste your migrations above to see which tables would need one.

What changed on October 30, 2026?

Supabase’s schedule applied 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.

My migration works locally. Why does it fail on the hosted project?

Check your Supabase CLI version. Since CLI v2.106.0 (June 11, 2026), supabase start and supabase db reset also leave new tables in public without Data API grants, so older CLI versions can hide the problem until you deploy. Update the CLI and add the grants to the migration.

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, checked October 23, 2026: Supabase changelog: tables not exposed to the Data API automatically. Check the policies themselves with the Supabase RLS policy checker, and the live app with the free AI app security check. Using Firebase instead? Try the Firebase Security Rules checker. Other Supabase errors: Edge Function blocked by CORS and auth emails that link to localhost.

Link to this checker

Writing a migration guide, a README or a forum answer about the October 30 change? You’re welcome to link here. The checker is free, needs no sign-up, and never uploads the SQL.