Supabase RLS Launch Proof checklist
RLS being enabled is not enough. Before launch, prove the public key cannot read protected rows and that policies match the app model.
Supabase's public anon key belongs in the browser. The real launch question is whether your policies make that public key harmless. "RLS enabled" is a start, not proof.
Before launch
- Every user-data table has Row Level Security enabled.
- Policies use ownership or membership predicates, not broad
USING (true). - No service-role key appears in browser-visible code.
- Unauthenticated requests cannot read protected table counts.
- AI-generated migrations are reviewed before they run.
What Shipshape proves
The passive scan detects Supabase usage and dangerous key exposure. Owner verification unlocks read-minimal RLS probes. The MCP review_sql_policy tool reviews SQL migrations for missing RLS, permissive policies, unsafe grants, secrets, and destructive changes.
FAQ
Is RLS enabled enough to launch?
No. A table can have RLS enabled but still have overly broad policies. You need to prove what anonymous and authenticated roles can actually read.
Can Shipshape review SQL migrations?
Yes. The MCP tool review_sql_policy statically blocks common unsafe SQL patterns before an AI agent applies them.
Related questions
- Gemini/API key wallet-drain checklist for AI apps
- What Shipshape proof packs prove — and what they do not
- Is Shipshape legit? What it does and doesn’t do
- Supabase anon key vs service_role key: which is safe to expose?