Is your Supabase or Firebase backend actually locked down?
Only if you locked it yourself. Supabase and Firebase give you secure infrastructure, but they run on a shared-responsibility model: the platform protects itself, and your data-access rules are your job, and they do not turn on automatically. Supabase ships new tables with Row-Level Security off. Firebase projects often start in "test mode" that silently expires, so developers paste allow read, write: if true to fix it and ship it. This is the exact layer where the worst breaches happen: CVE-2025-48757 exposed 170+ Supabase-backed apps, and the Tea app leaked 72,000 images (including 13,000 IDs) through a public Firebase bucket. Veilguard checks whether your backend is actually protected and shows you the exact rule to add.
The shared-responsibility trap
Both platforms are secure by design, but "secure infrastructure" is not "secure app." Unlike a database sitting behind your server, Supabase and Firebase are directly accessible from the browser. Your app’s public config (the Supabase anon key, the Firebase config object) is visible to anyone, and that is intended, those are identifiers, not secrets.
The only thing standing between your data and the public internet is your rules: Supabase RLS policies and Firebase Security Rules. Founders assume the platform handles it. It doesn’t, and it never warns you. That gap is exactly what CVE-2025-48757 (Supabase RLS off) and the Tea breach (Firebase public bucket) exploited.
Where each backend leaks
Supabase
- RLS not enabled (Critical) new tables are open by default; the public anon key reads everything. The anon key is meant to be public; RLS is what makes that safe. Without it, it is a master key. (CVE-2025-48757: about 10% of scanned Supabase-backed apps leaked this way.)
- Permissive policies (Critical) USING (true), or auth-only policies that let any logged-in user read everyone else’s rows.
- service_role key exposure (Critical) the admin key bypasses all RLS; catastrophic if it reaches the browser. (Moltbook leaked 1.5M tokens this way.)
- Public Storage buckets (Warning) uploaded files readable by anyone.
- SECURITY DEFINER views views that run with elevated rights and skip RLS.
Firebase
- Open rules (Critical) allow read, write: if true leaves the whole database public, often pasted in from the console’s expired test mode. (The Tea app exposed 72,000 images including 13,000 IDs and 1.1M messages.)
- Auth’d-but-unscoped (Critical) allow read, write: if request.auth != null looks safe but lets any logged-in user read everyone’s data, the most common real Firebase mistake.
- Open Storage buckets (Critical) locking Firestore does not lock Storage; they are separate rule sets.
- Missing App Check (Warning) no protection against abuse or billing fraud from outside your app.
How to check
Because these backends are client-accessible, paste your live app’s URL into Veilguard and it probes what an anonymous or logged-in visitor can actually read, the same thing an attacker would do. Connect your repo for the deepest read of your actual rules files.
Live rule-probing is tuned for Supabase and Firebase. If your app uses Neon or MongoDB instead, see those guides, Veilguard scans your code for exposed connection strings and app-level access gaps, and the guide walks you through locking the database down yourself.