Firebase misconfiguration is one of the most common ways mobile apps leak data. Firebase is a popular backend, and its database, storage and configuration are easy to set up but also easy to leave open. When the access rules are too loose, anyone who reads the app can reach the data behind it. Only test apps and backends you are authorised to test.
What Firebase misconfiguration means
A mobile app ships with its Firebase configuration inside the package, including the project details and the URLs of the services it uses. That is by design. The security comes from the rules on the backend, which decide who can read and write the data.
Misconfiguration happens when those rules are missing or too permissive. The classic case is a rule left open for testing and never tightened, so the database or storage bucket is readable, or even writable, by anyone.
How it leaks data
| Service | The misconfiguration |
|---|---|
| Realtime Database / Firestore | Read or write rules left open, so records can be pulled or changed without authentication. |
| Cloud Storage | A bucket that allows public read, exposing uploaded files and documents. |
| Configuration and keys | Project configuration and API keys in the app used in ways that allow more access than intended. |
Because the configuration is the same for every install, one open rule exposes the data for the whole user base at once, which is what makes this a high-impact finding.
How to find it
- Extract the configuration. Pull the Firebase project details, database URLs and storage buckets from the shipped APK or IPA. This is a static step.
- Check the rules, with authorisation. For a project you own, confirm whether the database and storage rules require authentication and limit each user to their own data.
- Review the API key restrictions. Confirm the keys are scoped so they cannot be reused for more than the app needs.
Mobexa includes deterministic Firebase checks: it extracts the configuration from the build and reports exposed services as confirmed facts rather than guesses. See hardcoded secrets for the related credential risk.
How to fix it
The fix is on the backend, not the app. Write rules that require authentication and limit each user to their own records, lock storage buckets to authorised access, and restrict API keys to the services and apps that need them. Then re-check, because the only way to know a rule is safe is to confirm it.
For the broader context, read what is mobile application security.
Common questions
Is it bad that Firebase config is inside the app?
How do attackers find open Firebase databases?
What is the fix for an open Firebase database?
See it on one of your own apps
Mobexa tests the exact Android or iOS build you ship and maps every finding to the OWASP Mobile Top 10 and MASVS.
Start Free Trial