Firebase Security Rules Best Practices

Firebase's security model is genuinely powerful, but it's also one of the easiest places to make a quietly expensive mistake. Every new project starts locked down by default, which is the right instinct, but it's tempting to loosen a rule just to get something working during development, and that loosened rule has a way of making it into production and staying there unnoticed.

The short answer

Write rules around three principles: deny by default, scope every read and write to the data the requesting user actually owns, and validate data shape inside the rules themselves rather than trusting your app's client code to send well-formed data. A rule that only checks "is this user logged in" isn't really protecting anything, it's just checking a box.

Common mistakes worth knowing about

1. Rules left wide open from development

Firebase's test mode allows open read and write access for a limited window to make local development easier. It's meant to be temporary, but it's easy to forget it's there once the app is functionally working, and ship to production with rules that never actually got locked down.

2. Trusting client-side validation alone

Validating required fields and data types in your app code is good practice, but it isn't security. Anyone can call your Firebase project directly, bypassing your app entirely, so the rules themselves need to enforce data shape and types, not just decide who's allowed to write at all.

// Loose: only checks authentication, not data shape or ownership
match /orders/{orderId} {
  allow write: if request.auth != null;
}

// Tighter: checks ownership and validates the shape of what's being written
match /orders/{orderId} {
  allow write: if request.auth != null
    && request.resource.data.userId == request.auth.uid
    && request.resource.data.status is string
    && request.resource.data.total is number;
}

3. Inconsistent rules across related collections

A primary collection like orders often gets carefully scoped, while a related collection that references the same data, something like an assignment or status-tracking collection tied to those orders, gets left with looser rules because it feels secondary. The same data ends up protected one way in one place and exposed in another, which defeats the point of locking down the first collection at all.

4. Misreading identity in anonymous or phone-based auth

In apps using anonymous or phone-based authentication, the value in request.auth.uid doesn't always match the stable identifier your app actually uses to track a user, that mapping often lives in a separate user document instead. Writing rules that check request.auth.uid directly, when the app's real ownership logic depends on a different stored field, either blocks legitimate users unexpectedly or, worse, looks restrictive without actually restricting the right thing.

5. Forgetting to scope multi-tenant or multi-vendor data

In any system with more than one organization or vendor sharing the same database, "the user is authenticated" is not the same as "the user is allowed to see this specific record." Rules need an explicit check that the requesting user belongs to the vendor or organization that actually owns the record, not just that they're logged in at all.

6. Not testing rules before deploying

Rules can look correct when you read them and still allow or block the wrong thing once real nested data and document references are involved. The Firebase emulator suite lets you test rules against realistic data before they ever reach production, and it catches a category of mistakes that's nearly invisible from just reading the rules file.

A simple checklist

• Deny by default, then open up access explicitly, never the other way around.
• Scope every read and write to the resource owner, not just to "any authenticated user."
• Validate required fields and data types directly in the rules.
• Check every collection your data touches, including secondary or assignment-style collections, not just the obvious primary ones.
• Test with the emulator suite against realistic data before deploying.

Why this matters more than it seems

A misconfigured security rule doesn't usually show up as a crash or an error message, it shows up as silent, ongoing data exposure that can go unnoticed for a long time, since the app keeps working normally for legitimate users the entire time the gap exists.