Is your Firebase database open to the internet?
Quite possibly, and the dangerous part is the rule that looks safe. Firebase is directly accessible from the browser; your Firebase config (API key, project ID) is public by design, those are identifiers, not secrets. The only thing protecting your data is your Security Rules. The two rules that expose the most apps: allow read, write: if true (anyone in the world can read and write everything) and, more insidiously, allow read, write: if request.auth != null, which looks locked down but lets any logged-in user read and write everyone else’s data. The Tea app leaked 72,000 images through an open Firebase bucket. Veilguard probes your Firebase rules the way an attacker would and shows you what is exposed.
The "if request.auth != null" trap
This rule feels safe, "you have to be logged in." But if signup is open (it usually is), an attacker just creates an account, and now they are "authenticated" and the rule lets them read and write every user’s data, not just their own.
Security researchers exploit exactly this: self-signup, then read /users, then write arbitrary data. The rule has to match the owner, request.auth.uid == userId, not just "is authenticated."
Where Firebase apps get exposed
- allow read, write: if true (Critical): the whole database public, often pasted in from the console’s expired test mode.
- if request.auth != null, unscoped (Critical): any logged-in user reads and writes everyone’s data.
- Realtime Database root rules (Critical): permissive rules at the root cascade to everything below.
- Open Storage buckets (Critical): locking Firestore does NOT lock Storage, they are separate. (Tea: a public bucket, 72k images including 13k IDs.)
- Missing App Check (Warning): no protection against abuse or billing fraud from outside your app.
How hackers target Firebase
They read your Firebase config from your JS bundle (it is public), then hit the Firestore, Realtime Database, and Storage REST endpoints directly, no app UI needed. If the rules are open or auth-only, the endpoints answer. It is a few curl commands. That is the exact surface Veilguard tests.
Firebase and compliance
An open Firebase database leaking user PII (names, emails, photos, IDs) is not just a breach, it is a compliance failure. GDPR and similar laws require you to protect personal data; if true or unscoped rules mean you are not. The Tea breach led to class-action lawsuits. Locking your rules to per-user ownership is a baseline compliance requirement, not just good practice.
How to check and fix your rules
Open your firestore.rules, database.rules.json, and storage.rules. Red flags: if true, a bare if request.auth != null on user data, and if request.time < timestamp.date(...) (expired test mode). Use the Firebase Console Rules Playground to simulate requests as different users. Then scope every rule to ownership, and lock Storage separately from Firestore.
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}Before you launch on Firebase
- 1.No if true anywhere in your rules.
- 2.Rules scoped to request.auth.uid == ownerId, not just auth != null.
- 3.Storage rules locked separately from Firestore.
- 4.App Check enabled.
- 5.No expired test-mode rules left in place. The fastest check: paste your app’s URL into Veilguard and it reports what an anonymous or logged-in client can actually read.
Frequently asked
Why is "if request.auth != null" not enough?
Because signup is usually open, so anyone can become "authenticated" in seconds. That rule then lets any logged-in user read and write everyone else’s data. You have to scope the rule to the owner: request.auth.uid == userId.
Is my Firebase config safe to expose in the browser?
Yes, the config (API key, project ID) is an identifier, not a secret, and it is meant to be public. Your protection is your Security Rules. What is not safe is leaving those rules open or auth-only.
I locked my Firestore rules. Is my Storage safe too?
Not automatically. Firestore and Storage use separate rule sets, and locking one does not lock the other. The Tea breach was a public Storage bucket. Lock storage.rules to ownership as well.
Do I get the corrected rules?
Yes. Each finding includes the exact rule to paste into your rules file, or a prompt you can give your AI tool to apply it for you.
