5 checks in this theme
Supabase & Firebase security checks
Supabase RLS left disabled, permissive policies, Firebase rules, browser-direct database access — 5 checks for hosted-backend exposure in AI-built apps.
Your database is one policy away from public
The failure shape: tables created without Row Level Security, or with policies so permissive they might as well be off (USING (true)), Firebase rules that allow read and write to anyone, browser code talking straight to the database, and storage buckets whose contents are publicly listable. The loudest variant — a service-role key shipped in the bundle — is checked under secrets scanning.
Why AI tools generate it
Builder-style flows (Lovable, v0, and friends) are optimized to get a working app in front of you fast: tables get created, the anon key gets wired into the client, and the policy step — the one that requires deciding who may see what — is simply never part of the demo. Supabase creates tables with RLS disabled unless it is asked for; an AI tool does not ask.
How the scan detects it
Repo-side analysis of your migration and policy files, security-rules files, and client bundles for direct database usage — plus a strictly read-only probe of storage-bucket hints found in the repo (GET-only, no listing endpoints). Findings cite the exact file and policy, masked as usual.
The 5 checks
FAQ
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
Check your app — free
10 Critical checks, no signup, results in about two minutes. Every finding is masked and carries a paste-ready fix prompt.
Run the free scan