Firebase Security Rules Audit: the Firewreck Pattern in 2026
Three rule patterns that exposed Firebase apps in 2026, how to find them in your own project, and what each test result means.
Founder, Newly
Published Last updated
Open your Firebase rules and look for three things: a rule that is simply true, a rule that asks only for a signed-in user, and a Realtime Database rule high in the tree that cascades down. Any of the three can let strangers read your data. Test each as a signed-out user and as a second account, then mark it detected, unknown or confirmed by owner evidence.
What did Firewreck 2.0 find, and what does it mean for my app?
Firewreck 2.0 is a research write-up by the researcher MrBruh, published on January 28, 2026. It covers a scan of Android apps from December 17 to 24, 2025. The numbers below are the researcher's own, read from the write-up on October 24, 2026.
| Fact | What the source reports |
|---|---|
| Apps downloaded | 1.5 million Android apps |
| Apps with a valid Firebase config | 800,000 |
| Vulnerable instances | 11,126 |
| Exposed user records | 1,432,693,875 (about 1.43 billion) |
| Products affected | Firestore, Realtime Database, Storage and Authentication with open sign-up |
| Disclosure outcome | 9,889 notification emails sent; 228 instances fixed |
| A separate case | Malwarebytes, February 9, 2026: an AI chat app with rules set to public exposed about 300 million messages from about 25 million users; the vendor fixed it within hours of disclosure |
In both reports the cause was rules that let outsiders in while the app kept working for its owners, which is why nothing looked broken. The question for your own app is short: which of my rules would let a stranger in?
Why do the rules matter more than the Firebase config?
Firebase says that API keys restricted to Firebase services do not need to be treated as secrets, and that data in Realtime Database, Cloud Firestore and Cloud Storage is protected by Security Rules and App Check. In an Expo project the config object sits in a file such as firebaseConfig.js, as Expo's Firebase guide shows, and it ships inside the app. Anyone who installs the app can read it.
That makes the rules the one gate. Firebase's own page on insecure rules says that without authentication and rules, anyone who guesses your project ID can steal, modify or delete the data. For Realtime Database it is even plainer: any database URL with .json appended is a REST endpoint, and the rules decide whether it answers.
If you use the same idea with Supabase, the sibling page on testing row level security as the anon role walks through it.
Which rule patterns should I look for in my own project?
Open the rules for each product your app uses. If you downloaded your code or connected your own repository, they are in the project next to the app. The deployed copy in the Firebase console is the one that counts, so read both.
| Pattern | What it lets in | What to change |
|---|---|---|
allow read, write: if true or test-mode rules | Everyone, signed in or not. Firebase's guide describes test mode as allowing anyone to read and overwrite your data. | Replace with owner-scoped rules before real users arrive. |
request.auth != null alone | Any signed-in account, including accounts anyone can create. | Compare request.auth.uid with the owner's id, or check a claim you set yourself. |
| A grant high in a Realtime Database tree | Every path below it, because .read and .write cascade and a deeper rule cannot take access back. | Move grants down to the exact paths that should be public. |
| Storage rules with no limits | Uploads of any size and type from anyone the rule admits. | Add checks on request.resource.size and contentType. |
| Owner-scoped rule | Only the account whose id matches the record. | This is the shape to aim for. Test it before you trust it. |
The patterns come from Firebase's insecure rules guide, its rules basics, the Realtime Database rules page and the Cloud Storage rules page, checked on October 24, 2026. Rules are also not filters: a query that could return rows you may not read is refused as a whole, which is why an app that works for you can still hide a rule that is too wide.
Anonymous sign-in counts as signed in
Anonymous authentication creates a temporary account for a visitor, and that account is a signed-in user. A rule that checks only for a signed-in user cannot tell it from a customer. The rules auth reference lists firebase.sign_in_provider in the token, so a rule can name the method it accepts.
How do I test my rules without breaking my app?
1. Try each path as a stranger in the Playground
The Rules Playground in the Rules tab of each product simulates a request as an unauthenticated user, an anonymous user or a specific user id. Run a read and a write for every collection, path and bucket folder. Save the result.
2. Write tests that expect failure
Firebase documents local rules tests with the emulator and the @firebase/rules-unit-testing library: unauthenticatedContext, authenticatedContext, assertFails and assertSucceeds. The library works against the emulators and never touches production resources. Most people write only the passing cases. A suite where every test succeeds proves the app works and nothing about strangers, so add an assertFails for every read of another user's data.
3. Use two real test accounts
Sign in to the running app as the second account and request something that belongs to the first. This catches rules that look correct and are bypassed by a wider rule elsewhere. OWASP's Mobile Top 10 lists insecure authorization as M3 and security misconfiguration as M8; this test covers both.
4. Deploy, then repeat
The Firebase CLI deploys each product separately, as the deploy guide shows:
firebase deploy --only firestore:rulesfirebase deploy --only databasefirebase deploy --only storage
Run steps 1 to 3 again against the deployed rules. An Expo app that uses the Firebase JS SDK runs in Expo Go; React Native Firebase needs a development build, as its documentation explains. The rules behave the same either way.
Where does App Check fit?
App Check helps keep unauthorized clients away from Firestore, Realtime Database, Storage and callable functions, with App Attest on iOS and Play Integrity on Android. Firebase calls it complementary to Authentication. It checks which app is calling. It does not say which rows a signed-in user may read, so it does not replace the rules.
What does each test result mean?
| State | What you hold | Next step |
|---|---|---|
| Detected | A signed-out or second-account request that succeeded where it should not. | Tighten the rule, deploy it, rerun the same test. If the data was sensitive, treat it as exposed. |
| Unknown | Rules read but not tested, a path nobody listed, or a console copy you have not compared with the repository. | Run the Playground and an expect-failure test for it. Unknown is the honest default. |
| Confirmed by owner evidence | A saved refusal for each path, from the deployed rules, with the date. | Rerun after every rules change and before each release. |
A scan from outside cannot move an item to confirmed. If a website shares your Firebase project, the free scan on red.run.cloud lists keys in shipped bundles and services reachable from the internet, and what an external website scan cannot prove spells out the limits. For the wider app, the 15-minute check and the pre-launch review cover the rest, and leaked AI keys are a separate problem from rules, because those keys are secrets.
Where do you stand?
Everything starts as unknown. Move an item to confirmed only when you hold the evidence listed under it, taken from the deployed rules.
Your Firebase rules audit
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Is Firebase itself the problem?
Firewreck 2.0 counted apps whose rules let outsiders in. Firebase's documentation says access to Realtime Database, Cloud Firestore and Cloud Storage data is enforced by Security Rules, so the rules you wrote or accepted decide the outcome. Check the rules file and the deployed copy in the console.
Does hiding my Firebase config help?
No. Firebase documents that API keys restricted to Firebase services do not need to be treated as secrets, and anyone who installs your app can read its config. Spend the effort on the rules and on App Check instead.
Does a rule that requires a signed-in user protect my data?
Only against signed-out strangers. A rule that checks nothing beyond request.auth != null lets every signed-in account read what it covers, including accounts that anyone can create and anonymous ones. Scope each rule to the owner, for example by comparing request.auth.uid with the owner's id.
Can I tell whether someone already read my data?
Not from the rules file. An open rule shows that reads were possible, not that they happened. If the data was sensitive and the rules were open, treat it as exposed: lock the rules now, rotate anything stored in the database, and decide with legal advice whether you must notify users.
Does Newly set my Firebase rules?
Newly builds a real iPhone and Android app with React Native and Expo, and you can download your code or connect your own repository. Whether your app uses Firebase, and what its rules say, sits in your project and your Firebase console, so read them there.
Will the free red.run.cloud scan check my Firebase rules?
No scan from outside can read your rules file. The free scan reads the stack a live site serves, looks for keys in shipped bundles and lists databases and services reachable from the internet. It is useful for a website that shares your Firebase project, and it cannot confirm that your rules are locked.
Sources
Firebase and Expo pages were read on October 24, 2026. The Firebase pages showed last-updated dates of October 20 and 21, 2026.
- Firewreck 2.0, January 28, 2026, MrBruh (researcher write-up)
- AI chat app leak exposes 300 million messages, February 9, 2026, Malwarebytes
- Avoid insecure rules, Firebase docs
- Security Rules basics, Firebase docs
- Security Rules and Firebase Authentication, Firebase docs
- Realtime Database Security Rules, Firebase docs
- Realtime Database REST API, Firebase docs
- Cloud Storage Security Rules, Firebase docs
- Learn about using and managing API keys for Firebase, Firebase docs
- Firebase App Check, Firebase docs
- Rules Playground, Firebase docs
- Build unit tests for Security Rules, Firebase docs
- Manage and deploy Security Rules, Firebase docs
- Anonymous authentication, Firebase docs
- Get started with Cloud Firestore (test mode), Firebase docs
- Using Firebase, Expo docs
- React Native Firebase, rnfirebase.io
- OWASP Mobile Top 10, OWASP Foundation
Back to the security hub.