Supabase Grant Migration Builder
Turn a redacted table/function intent matrix into a reviewable Data API grants migration, default-privilege revoke block, and role-matrix test packet before the 2026 explicit-grants rollout.
1
Grant before guessing at RLSSeparate role reachability from row authorization so
42501 errors do not become broad-policy fixes.2
Default privileges firstStart from opt-in table, sequence, and function exposure, then add narrow grants only for intended callers.
3
Local redacted packetNo network request, analytics, browser storage, backend upload, or private project data is used by this page.
Line format: table object privilege role note, function object(signature) execute role note, or sequence object usage role note. Example output includes grant select on table public.project_notes to authenticated;.
This page runs locally in the browser. Draft SQL still needs human review in a migration branch. Function grants need exact signatures. Do not paste credentials, service-role keys, customer rows, private screenshots, payment data, full names, or private account records.
Ready.
Reviewable migration packet
What to run after the migration
- No-session Data API read against every public table should fail unless the table is intentionally public.
- Anon-role calls should match only public-content grants and policies.
- Authenticated owner, wrong-owner, and wrong-tenant calls should prove RLS still blocks unintended rows.
- Every callable RPC should have a positive allowlist grant and anon/authenticated REST/RPC smoke-test evidence.
- Generated migrations should be rechecked for broad grants, missing RLS, and default function
EXECUTEexposure.
Source-backed problem set
Supabase changelog
The explicit-grants rollout changes the default exposure model for Data API objects.
Securing the Data API
Official docs separate grants, RLS, function EXECUTE, and default privilege hardening.
Row Level Security
Official docs describe exposed-schema RLS, explicit role policies, and auth.uid null behavior.