Modern Security Tooling (Part 2/3): Your APK Is Not a Vault (Firebase Recon)
Part 2 of a 3-part series on open-source security tooling. Part 1 covered AppSec tooling in Go. This one is about mobile apps and the cloud backends behind them.
Here's something that catches a lot of mobile developers off guard: your Android APK or iOS IPA is not a locked vault.
Run jadx on an APK, or unzip an IPA, and within a minute you can pull out the client configuration and see exactly which cloud backend the app talks to.
That's why Firebase and Cloud Storage misconfigurations are still a common, high-impact finding in bug bounty programs and mobile penetration tests.
OpenFirebase
🔗 Icex0/OpenFirebase
OpenFirebase (by Icex0) automates this audit. It extracts the Firebase configuration from APKs, IPAs or web apps, then checks for unauthorized read and write access on:
- Cloud Firestore
- Realtime Database (the .json REST endpoints)
- Cloud Storage buckets
- Remote Config and Cloud Functions
It also detects hardcoded service account keys, which, unlike the API key below, really are secrets.
The myth: "my Firebase API key leaked!"
When a scanner flags apiKey: "AIzaSy..." inside a mobile app or a frontend bundle, developers panic and assume their root credentials were stolen.
To be accurate: a Firebase apiKey is an identifier, not a secret. It tells Google which project to route requests to, and it's meant to ship inside the client.
The actual disaster isn't the key. It's what happens when database rules like these reach production:
// The classic development shortcut that never gets fixed:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true; // anyone on earth can read and write your data
}
}
}
With rules like that, nobody needs a zero-day. Anyone who knows the project ID can query the REST API directly and dump every user profile, payment record or internal document.
How to protect your mobile backend
1. Treat the client as untrusted. Never assume an API key, endpoint or collection name is secret just because it's compiled into the app.
2. Write strict security rules. Never ship if true. Require authentication (request.auth != null) and check ownership (request.auth.uid == resource.data.userId).
3. Test your rules in CI. The Firebase Emulator Suite lets you unit-test security rules before a build reaches the app store.
4. Audit your Cloud Storage buckets. Buckets shouldn't grant allUsers read or list access unless they really are serving public static assets.
Tools like OpenFirebase make these gaps easy to find. Scan your own apps before someone else does, and only test apps you own or are authorized to test.
Have you ever audited your mobile apps for open database rules or exposed buckets? Let's discuss in the comments.
Mentions
Modern Security Tooling (Part 2/3): Your APK Is Not a Vault (Firebase Recon) Part 2 of a 3-part series on open-source security tooling. Part 1 covered AppSec tooling in Go. This one is about mobile apps and the cloud backends behind them. Here's something that catches a lot of mobile developers off guard: your Android APK or iOS IPA is not a locked vault. Run jadx on an APK, or unzip an IPA, and within a minute you can pull out the client configuration and see exactly which cloud backend the app talks to. That's why Firebase and Cloud Storage misconfigurations are still a common, high-impact finding in bug bounty programs and mobile penetration tests. OpenFirebase 🔗 Icex0/OpenFirebase OpenFirebase (by Icex0) automates this audit. It extracts the Firebase configuration from APKs, IPAs or web apps, then checks for unauthorized read and write access on: - Cloud Firestore - Realtime Database (the .json REST endpoints) - Cloud Storage buckets - Remote Config and Cloud Functions It also detects hardcoded service account keys, which, unlike the API key below, really are secrets. The myth: "my Firebase API key leaked!" When a scanner flags apiKey: "AIzaSy..." inside a mobile app or a frontend bundle, developers panic and assume their root credentials were stolen. To be accurate: a Firebase apiKey is an identifier, not a secret. It tells Google which project to route requests to, and it's meant to ship inside the client. The actual disaster isn't the key. It's what happens when database rules like these reach production: // The classic development shortcut that never gets fixed: service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if true; // anyone on earth can read and write your data } } } With rules like that, nobody needs a zero-day. Anyone who knows the project ID can query the REST API directly and dump every user profile, payment record or internal document. How to protect your mobile backend 1. Treat the client as untrusted. Never assume an API key, endpoint or collection name is secret just because it's compiled into the app. 2. Write strict security rules. Never ship if true. Require authentication (request.auth != null) and check ownership (request.auth.uid == resource.data.userId). 3. Test your rules in CI. The Firebase Emulator Suite lets you unit-test security rules before a build reaches the app store. 4. Audit your Cloud Storage buckets. Buckets shouldn't grant allUsers read or list access unless they really are serving public static assets. Tools like OpenFirebase make these gaps easy to find. Scan your own apps before someone else does, and only test apps you own or are authorized to test. Have you ever audited your mobile apps for open database rules or exposed buckets? Let's discuss in the comments.