In our recent analysis of the Tea data exposure incident, where user-uploaded media and identity documents from a fast-scaling women’s safety app were left publicly accessible, we identified a common root cause: Firebase misconfiguration.

The Tea case is not unique. Throughout 2025, Dvuln has investigated numerous incidents linked to Firebase deployments that lacked proper access controls. These exposures are not due to technical flaws in Firebase itself. Rather, they stem from developer shortcuts, lack of access rule validation, and unsafe deployment defaults.

This article outlines the most common Firebase misconfigurations encountered by Dvuln and offers clear guidance on how to prevent them in production.

Why Firebase Defaults Are Dangerous

When spinning up a Firebase project—whether Firestore, Realtime Database, or Cloud Storage—developers are offered two rule modes:

• Locked Mode, which blocks all access until explicit rules are defined

• Test Mode, which permits full unauthenticated read and write access without alerting the developer or requiring credentials

Test Mode is intended for development use. However, in real-world scenarios, it is frequently left enabled beyond the intended period, often being deployed into production environments. This occurs because Firebase does not enforce rollback or expire unsafe rules automatically. The platform allows deployment of permissive configurations without issuing warnings to the development team.

A frequently observed rule left behind in production looks like this:

allow read, write: if true;

This configuration grants full unauthenticated access to the entire database. Firebase’s documentation clearly states that this rule should never be used in production. However, the absence of enforcement or in-product warnings results in persistent exposure across otherwise mature platforms.

Misinterpreting Authentication Checks

Another common failure involves overly permissive authentication rules:

allow read, write: if request.auth.uid != null;

Although this rule requires that the user be logged in, it grants access to all authenticated users. For applications with open registration or social login capabilities, this is functionally equivalent to global read and write permissions. It fails to restrict access based on ownership or role, and has led to exposure of user data including messages, documents, images, and booking information.

Enforcing Ownership in Rules

For basic access control, permissions must be tied to the identity of the user and the structure of the document being accessed or modified. The rule logic must validate ownership at both the data layer and the request layer.

Example:

jsCopyEditservice cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {

      allow read, delete: if request.auth.uid == resource.data.author_uid;

      allow create: if request.auth.uid == request.resource.data.author_uid;

      allow update: if request.auth.uid == resource.data.author_uid
                 && request.auth.uid == request.resource.data.author_uid;
    }
  }
}

This ruleset:

• Allows reads and deletes only if the current user is the owner of the document

• Allows creates only if the author_uid in the new document matches the user performing the request

• Allows updates only if ownership is consistent in both the existing and incoming versions of the document

Failure to validate both resource.data and request.resource.data results in unauthorised document manipulation and identity spoofing vulnerabilities. This validation is not optional. It is the minimum requirement for secure data ownership enforcement within Firebase.

Role-Based and Attribute-Based Access Control

Not all use cases map to a simple user-owns-document model. Applications that support collaboration, administrative functions, or tiered user permissions require role- or attribute-based access.

Firebase does not provide a built-in roles engine. However, roles can be defined in a dedicated users collection and evaluated within the ruleset via get() calls.

Example:

jsCopyEditservice cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader";
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer";
    }
  }
}

This method allows centralised role assignments and flexible permissions. Roles can be changed at runtime by updating the user document. The same pattern can be extended to include conditions such as:

• Membership in a team (team_id)

• Feature flag access (beta_access)

• Quota limits

• Scheduled time-based access

Quota and Billing Implications of Role Checks

Every get() operation within a Firebase rule counts as a document read—even if the rule fails and access is denied. In high-traffic environments, role checks can rapidly consume Firestore read quotas, resulting in increased cost or degraded performance.

Dvuln recommends the following mitigations:

• Keep user documents used for role checks minimal and indexed

• Use compound conditions to short-circuit unnecessary lookups

• Do not cache role enforcement logic client-side

• Profile all rulesets using the Firebase Emulator Suite before production deployment

Realtime Database Inheritance: A Structural Risk

Unlike Firestore, Realtime Database uses hierarchical rule inheritance. Permissions granted at a parent node are automatically inherited by all child paths, and cannot be overridden at lower levels.

Example:

jsonCopyEdit{
  "rules": {
    "foo": {
      ".read": "data.child('baz').val() === true",
      "bar": {
        ".read": false
      }
    }
  }
}

In this configuration, .read: false on bar is ignored because foo already grants access. This behaviour is not immediately visible in the Firebase Console and can result in critical subpaths being unintentionally exposed.

Recommendations:

• Avoid assigning read access at high-level paths unless absolutely required

• Isolate sensitive data into clearly defined top-level nodes with explicit rules

• Never rely on indentation or visual structure as a proxy for access boundaries

Closed Access Rules: Secure But Operationally Fragile

In response to risk, some teams deploy the following rule:

jsCopyEditallow read, write: if false;

This blocks all direct Firebase access. While secure, it breaks functionality if the front end is not explicitly designed to interact only through secure backend APIs.

This rule is appropriate only when:

• All Firebase interactions are handled through the Admin SDK or Cloud Functions

• There are no direct reads or writes from mobile or web clients

• The development team has validated every runtime access flow

If used without alignment across the stack, this rule results in silent application failure. Front ends will appear broken, data will not load, and error messages may be absent or misleading.

Managing Firebase Rules as Code

Firebase rules can be edited via the Firebase Console or via the Firebase CLI. If a change is made in the console and not committed to source control, the next firebase deploy will overwrite it silently.

Dvuln recommends the following:

• Store all Firebase rules in version-controlled files

• Use the CLI for all rule deployments

• Avoid console edits unless applying emergency patches in a controlled environment

• Treat access control as code: include in pull requests, require reviews, and enforce policy enforcement gates

The Firebase Console does not show what exists in source control. It only displays the active deployed ruleset. That mismatch introduces risk.

Testing Access Rules

Firebase provides two tools to validate access rules:

1. Firebase Emulator Suite
   Allows local simulation of Firestore, Realtime Database, and Storage. Should be integrated into both development workflows and CI pipelines.

2. Firebase Rules Simulator
   A visual tool in the Console to test single read or write operations against given auth contexts and paths.

Both tools should be used before any production deployment. Firebase does not emit errors for insecure rules. It applies whatever is written.

Final Recommendations

Firebase does not inherently introduce risk. Misconfigured rules do.

If a development team has not conducted a full structured review of deployed Firebase rules, there is a high likelihood of exposure. Most of the breaches Dvuln has investigated in 2024 and 2025 have involved permission design flaws, not software bugs.

Recommendations:

1. Pull and audit all deployed Firebase rules across projects

2. Remove allow read, write: if true wherever found

3. Use scoped ownership or role logic for all access paths

4. Enforce rules management via CLI and version control

5. Validate all rules in Emulator Suite before production rollouts

Misconfigured Firebase rules are not a documentation issue. The risks are clearly stated by Google. They are an operational discipline issue. Dvuln assists organisations in uncovering these exposures before they become headlines.

To schedule a structured Firebase configuration review or include Firebase testing in your next red team or penetration test engagement, contact the team at Dvuln.