Supabase Permissive Policy Check — Does Your Policy Allow-Read to Everyone?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
A Supabase policy that literally says anyone can read (or write) a table — like USING (true) — puts the data one DNS query away from the public, regardless of RLS being 'on'.
Why AI tools generate it
AI tools generate permissive 'allow all' policies to make a demo spring to life, and leave them in place because they never run the app from an anonymous perspective.
How DevMeth detects it
The live probe inspects your published policies (Supabase exposes them) and flags any that grant unauthenticated read/write, distinguishing an open table from a correctly-closed one.
Your Supabase tables are readable by anyone — the policy says so, literally
WHAT WE FOUND
policy "anon_read" ON users FOR SELECT — USING (true)
The fix, in three steps
Replace USING (true) with a policy anchored to auth.uid(), then re-scan to confirm the anonymous read returns zero rows. Three steps.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.