supabase-grants-check: see who can reach your tables before the 30 Oct grants change

[lagudafuadtosin]

On 30 Oct 2026 Supabase stops giving new public tables to anon, authenticated and service_role on existing projects. Old tables keep their grants. New ones are closed until you grant them, and the app gets 42501.

My server reads tables with the service role, so the next table I add after 30th would fail, and not just for my own backend but also for users.

So I wrote one SQL file you paste into the SQL editor. It only reads, it changes nothing. It gives back one table:

• who gets your new tables today, and after 30 Oct
• tables open to the API with row level security off
• tables your server key cannot read
• views the API can reach
• functions a signed out visitor can call, flagged hardest when they are security definer

Each row has the exact line to paste if you decide to change something and nothing runs for you.

I myself have tested it on Postgres 18 with the 3 Supabase roles and it works fine.

https://github.com/lagudafuadtosin/supabase-grants-check

MIT, and pls tell me if something goes wrong, so I can fix it

[cekuu35]

This is the right pre-flight for the date, and the service_role catch (your own backend, not just client reads) is the one that actually surprises people — most "Oct 30" write-ups only cover anon.

One complementary check that pairs with it: the policy-side of the same change. Your file covers grants (who can reach the table); the other half is whether the policies those grants unlock are actually scoped. The class I find most in the wild: policies with a correct-looking predicate but no TO clause — Postgres evaluates those for PUBLIC, so anon gets in even though the name says "Users can view X":

select tablename, policyname, roles
from pg_policies
where schemaname = 'public' and roles::text = '{public}';

Every row is a policy the anon key can hit. Pairing your grants-check with this gives the full picture — grants answer "can they reach it," policies answer "what do they get once they do." (Policy side written up here, with the self-healing pattern for tables created after the date: https://dev.to/cekuu35/supabases-default-privileges-expose-every-new-table-heres-the-self-healing-fix-43jn )

Two additions worth folding into grants-check if you extend it:

1. ALTER DEFAULT PRIVILEGES state for the postgres role — that's the line that actually decides what a post-Oct-30 table inherits, and it's the one people will want to keep or change.
2. Views built on security definer functions — a view can be anon-reachable even when every base table's grants are clean, which your "views the API can reach" row would catch nicely.

The "changes nothing / read-only" guarantee is what makes this safe to run on production — good call shipping it that way.

[lagudafuadtosin]

hmm, both additions are already in check.sql.

You see, it lists the postgres default privileges that decide who gets new tables, warns on every view the api can reach because views skip row level security unless made with security_invoker, and flags security definer functions a signed-out visitor can call

Then on the to clause, a policy with no to only lets anon in when its rule passes for anon, so auth.uid() = user_id gives anon nothing and the real risk is rules like using (true)

that part is policies rather than grants, so I will keep this one a grants check

[cekuu35]

Fair corrections on both — you're right, and I re-tested the mechanics rather than argue: a TO-less policy with an auth.uid() predicate does evaluate for anon, but auth.uid() is NULL in that context, so the predicate fails and anon sees nothing. The class I should have scoped to is TO-less plus a predicate that passes for anon — using (true), is_public flags — which is the actual leak shape I keep finding in real audits (policies named "Users can view X" written as using (true) with no TO: a genuine leak, but for a different reason than I stated).

So my pg_policies query catches two populations and only one is an exposure: the anon-passing subset are leaks; the auth.uid()-with-no-TO subset are hygiene. Good distinction to keep sharp — and point taken that it's policy-side rather than grants. Keeping grants-check as a grants tool is the cleaner scope.