Firebase Realtime Database Rules Misconfig: Open Paths That Leak Data
Firebase Realtime Database ships with rules that decide who can read or write each path. Misconfigs still show up in bounty programs: ".read": true on /users, open /config, or rules that only check auth != null without binding auth.uid to the path.
The database URL is often public in the mobile/web client. That is normal. Open rules are not.
Recon without being reckless
From the app’s JS or APK, collect databaseURL (and project id). Confirm the surface is in scope. Some apps talk to a second “legacy” database still referenced in an old build flavor — check all clients.
Probe with the REST API or a minimal SDK client using your test user (and, if rules allow, unauthenticated access):
GET https://<db>/.json— if this returns data unauthenticated, stop after proving structure; do not scrape entire production trees- Path guesses from client code:
/users/{uid},/chats,/presence,/orders - Compare unauthenticated vs authenticated vs “another uid” access
- Shallow queries with
print=silent/ limited depth where available to reduce blast radius while testing
World-writable paths (".write": true) are as serious as reads — plant a canary node under a path you own, then show an unauthenticated write. Delete your canary when done if the program expects cleanup.
Rule bugs that keep recurring
- Authenticated-any-user read on
/users(IDOR across all profiles) auth.uid != nullwithout matching$uid- Legacy open rules left on staging DB still pointed at by a production build flavor
- Parent path open while children look locked — inheritance matters
- Validation-only rules that skip auth
- Rules that trust client-supplied
auth.token.adminclaims without Custom Claims being set server-side
Read Google’s Realtime Database security docs before arguing severity; map your PoC to the exact rule mistake. Firestore is a sibling product with different rule syntax — do not mix them up in the writeup title.
Ethical PoC
Prefer your own uid’s data and a single cross-uid read that returns a marker you planted on a second test account. Redact unrelated user records. Programs hate bulk exports of customer PII in attachments.
If the root is wide open, screenshot a shallow key list and describe blast radius — do not attach a full dump. Offer to retest after they tighten rules.
Remediation language
Least privilege rules, uid-scoped paths, tested rules in the emulator, no world-readable PII trees, monitor rule changes in CI. Mention that “auth required” alone is not tenant isolation. Deny by default, then open the minimum paths the client truly needs.
Firebase misconfigs are often Critical when PII is exposed and Quick wins when the client already shipped the database URL. Keep the proof small and the rule analysis precise.
If the program also ships Cloud Storage or Firestore, note them as separate surfaces — an open RTDB does not automatically mean those are open, and mixing them in one report confuses triage.