How to fix a publicly readable Firebase Realtime Database
Your Firebase Realtime Database is world-readable because its security rules allow unauthenticated reads. Here's how to confirm it, lock it down, and handle the exposed data.
Last updated 2026-09-05
".read": true). Fix it by changing the rules to require authentication, then assume the data was accessed and audit accordingly. The database URL shipping in your app is not the problem — the open rules are.Read in context. These instructions need to be adapted to your app and platform version. New scans provide static detections; they do not establish current backend access. Current methodology.
How to tell if yours is exposed
Firebase RTDB exposes a REST endpoint. If appending /.json to the database URL returns data without a token, it is world-readable. Do this only against your own project:
curl -s "https://YOUR-DB.firebaseio.com/.json"
# returns your JSON = open · {"error":"Permission denied"} (HTTP 401) = locked down
apk-scanner.com provides static findings, build details and analysis coverage. Scans check whether a referenced backend answers an unauthenticated request, never using a detected credential and never reading stored data. Review the current methodology and each report’s limitations.
Why it happens
Firebase's old default rules were open, and many projects ship with test rules (".read": true, ".write": true) that were never tightened before release.
The fix — require authentication
In the Firebase console (Realtime Database → Rules), replace open rules with rules that require an authenticated user, and scope access per user where possible:
{
"rules": {
".read": "auth != null",
".write": "auth != null"
}
}
For per-user data, nest rules so a user can only read their own node rather than the whole tree. Publish, then re-test with the /.json check above.
Cloud Firestore and Storage
The same class of mistake affects Cloud Firestore (allow read: if true;) and Firebase Storage buckets. Tighten those rules to if request.auth != null and scope by path/owner.
After you fix it
If the database was open, treat the data as having been accessed: notify affected users where required, rotate any secrets that were stored in it, and review Firebase usage metrics for anomalous reads. This maps to MASVS-STORAGE-2 (preventing data leakage).
Frequently asked questions
Is having a Firebase URL in my app a vulnerability?
No — the database URL is meant to be in the client. The vulnerability is security rules that allow anyone to read or write without authentication.
Does apk-scanner.com read my database contents?
A scan asks only whether the database answers an unauthenticated request. It never uses a detected credential and never reads your data. References alone do not establish public access.
How do I check Firestore or Storage instead?
Both have their own rules. Firestore uses allow read/write match rules; Storage uses similar rules per path. Require request.auth != null and scope by owner. A scan flags all three.