DevMeth
C7

Exposed data

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.

C7
What a finding looks like
Critical

Your Supabase tables are readable by anyone — the policy says so, literally

WHAT WE FOUND

policy "anon_read" ON users FOR SELECT — USING (true)

Sample — illustrative and masked exactly as a real report shows it. Run a free scan to see your own results.

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 scan

FAQ

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.