The 2024 Firebase Misconfiguration: How 916 Sites Exposed 125 Million User Records

In March 2024, three independent security researchers (Logykk, xyzeva (Eva), and MrBruh) published findings from an internet-scale scan that revealed a quiet but massive data exposure. After examining more than five million domains, they identified 916 websites whose Google Firebase backends were left open to the internet. The databases held more than 125 million user records, including roughly 19.9 million plaintext passwords, 106 million email addresses, 84 million names, 34 million phone numbers, and 27 million billing records containing bank details.

Google itself was not breached. No sophisticated exploit was required.

The root cause was almost always the same: missing or overly permissive Firebase Security Rules. Because Firebase is designed for client-side applications to talk directly to the database, those rules are the only access-control layer. When they are set to allow unauthenticated reads (and often writes), anyone who discovers the project configuration can query the data.

How the Research Worked

The effort began with a narrower finding. The researchers had previously examined the AI hiring platform Chattr and discovered that its Firebase configuration allowed them to register a new user and obtain administrative privileges. That prompted a broader scan.

An initial Python scanner that searched for Firebase configuration values in websites and JavaScript bundles consumed too much memory. Logykk rewrote it in Go. The new scanner processed approximately 5.2–5.5 million domains over two to three weeks and produced a list of candidates. Eva then built a secondary tool called Catalyst that checked for readable collections, sampled 100 records from each, and extrapolated impact. Results were stored in a private Supabase database.

The extrapolated totals (which the researchers noted were likely underestimates) were:

Notable exposures included Silid LMS (a learning management system with ~27 million user records), Lead Carrot (a cold-calling lead generator with ~22 million records), MyChefTool (a restaurant management platform with millions of names and emails), and an Indonesian online gambling network of nine sites that exposed roughly 8 million bank account details and 10 million plaintext passwords. The researchers also identified a bank among the affected organizations.

Why This Happened

Firebase Security Rules (for Realtime Database, Firestore, and Storage) are declarative and evaluated on every request. Common failure modes include:

• Development or “test mode” rules left in production (allow read, write: if true; or the equivalent Realtime Database .read: true, .write: true).
• Rules that check only authentication (request.auth != null) without checking authorization, so any logged-in user can read every document.
• Inherited or cascading rules that unintentionally grant broader access than intended.
• Storing passwords (or other secrets) in plaintext fields even though Firebase Authentication is designed so that application databases never hold passwords.

Firebase configuration values (API key, project ID, database URL) are intentionally public in client-side code. They identify the project; they do not authorize access. When rules are open, those public values become a direct path to the data. Eva noted that most of the exposed sites also allowed writes, which is particularly dangerous.

The researchers spent roughly two weeks sending 842 notification emails. About 85% were delivered, 9% bounced, and only about 24% of the site operators fixed the misconfiguration. One percent replied. Two sites offered bug bounties. Some operators, particularly in the gambling network, responded dismissively.

The Broader Pattern

This was not an isolated event. Subsequent research has repeatedly confirmed the same class of issue. In early 2026, scanners examining iOS and Android AI applications found extremely high rates of open Firestore rules and Storage buckets. Individual cases continue to surface, including the 2025–2026 Quittr app incident in which a popular anti-porn accountability application exposed intimate user data (including data on minors) because its Realtime Database rules allowed broad read and write access. Researchers had warned the operators months earlier.

The pattern is consistent: Firebase’s developer experience prioritizes speed. Default or tutorial rules are permissive so that prototypes work immediately. Many teams never replace them with production rules that enforce least privilege, ownership checks, and authentication requirements.

Because there is no traditional application server mediating access, a single misconfigured rule exposes the entire dataset.

Prevention Lessons

The technical fixes are straightforward and well documented by Google:

1. Deny by default. Initialize new Firestore instances in production mode and Realtime Database instances in locked mode. Never ship if true or equivalent open rules.
2. Authenticate and authorize. Require request.auth != null and ownership or role checks (for example, request.auth.uid == userId). Avoid granting any authenticated user access to every document.
3. Use Firebase Authentication. Do not store passwords (or password hashes that the application itself manages) in the database. Let Firebase Authentication handle credentials.
4. Protect Storage the same way. Cloud Storage security rules must be as strict as database rules; open buckets have produced many parallel leaks.
5. Review and test rules. Use the Rules Playground, unit tests, and the Firebase console’s warnings. Periodically scan for open collections. Tools and external scanners exist because this class of error is common.
6. Treat client configuration as public. Design assuming an attacker has the project ID and API key. Security must live in the rules, not in obscurity.
7. Monitor and respond. Enable audit logging where available. Have a process for handling external reports of open databases; the low remediation rate in 2024 shows that many operators ignored clear notifications.

Organizations that build on Firebase (or similar client-direct platforms such as Supabase) need security rules treated as production code: reviewed, tested, and version-controlled. Leaving them in development mode is equivalent to deploying a database with the front door open and the keys under the mat.

The 2024 research demonstrated that a relatively simple, automated scan could surface more than 125 million exposed records across hundreds of organizations. The underlying mistake remains easy to make and continues to appear years later. The remedy is equally simple: write and enforce rules that actually restrict access.