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
Does RLS enabled mean my table is safe?
Not by itself. RLS must be enabled AND every table needs non-permissive policies; a USING (true) policy reopens the table even with RLS on.
How do you see my policies?
Supabase exposes policy metadata to the same anonymous caller; the probe reads it read-only, exactly as a visitor could, and reports permissive grants.
What is a safe policy?
One scoped to the owner, e.g. CREATE POLICY ... USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id).
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.