Firebase Security Rules Mistakes AI Coding Tools Make

In a Firebase app there is usually no server between the client and the data. The web or mobile SDK reads and writes Firestore, Realtime Database and Cloud Storage directly using a project configuration that ships inside your JavaScript bundle. Firebase's own documentation puts it plainly: Firebase allows clients direct access to your data, and Firebase Security Rules are the only safeguard blocking access for malicious users.

That is the thing AI coding tools most often get wrong, because it is invisible in the preview. The generated app renders, the signed-in test user sees their own documents, and nothing on screen reveals that the rule allowing that read also allows any visitor with the project ID to read every document in the collection.

The same documentation warns that if you deploy your app it is publicly accessible even if you have not launched it. A staging deploy, a Vercel preview or a Firebase Hosting URL you sent to two friends is enough. If the rules are open, the data is open.

When you create a Firestore database or a Storage bucket in the console you pick a starting mode. Firebase describes test mode as good for getting started with the mobile and web client libraries, but allows anyone to read and overwrite your data. Production mode, sometimes called locked mode, denies all reads and writes from mobile and web clients while server-side Admin SDK code still works.

The test-mode ruleset the console writes includes a time condition of the form request.time < timestamp.date(...) with a date shortly after the project was created. That line is the only thing standing between your data and the public, and it is a timer, not a lock. AI tools have a bad habit with it: when the date passes and every client call starts failing, the tool's fix is to move the date out or delete the condition, which quietly makes the database open forever.

Search your rules for timestamp.date. If it is there, you are in test mode whether or not you meant to be. Replace the whole match block with rules that name real collections and check real ownership, as in the snippet below.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
        && request.auth.uid == userId;
    }
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Firebase's insecure-rules guide calls this open access and says that anyone with your project ID can steal, modify or delete your data without authentication. It shows up in three spellings: allow read, write: if true in Firestore and Storage, allow read, write with no condition at all in Storage, and ".read": true with ".write": true in Realtime Database.

AI tools produce it in two ways. The first is a permission-denied error during development, which the tool fixes by widening the rule until the error goes away. The second is a request like "make the leaderboard public", where the tool opens the whole database instead of the one collection you asked about.

The fix is never to hide the project configuration. Firebase's config is meant to be public; it identifies your project, it does not grant privileges. The fix is a rule that requires authentication and then narrows to the specific documents that user may touch.

The most common rule in generated Firebase projects is allow read, write: if request.auth != null. It looks like security because it mentions auth. Firebase lists it under insecure rules as access for any authenticated user and explains that while it requires login, it grants access to all authenticated users without further restriction on specific data.

In practice that means any person who creates an account, including an attacker who signs up with a throwaway email or anonymous auth, can read and edit every other user's documents. The rule answers "is this a user?" when the question is "is this the user who owns this document?". Firebase's fix is to narrow access using security conditions that compare request.auth.uid against the document's path or a field in the document.

Realtime Database has the same shape with ".read": "auth.uid !== null". The fix uses a wildcard for the user key and compares it: "$uid === auth.uid". Realtime Database rules cascade from parent to child, and a permissive rule at a shallow path overrides anything stricter below it, so put the auth check at the user node, not at the root.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

The ownership pattern in Firebase's docs is allow read, write: if request.auth != null && request.auth.uid == userId, where userId is a wildcard segment of the document path. Generated projects often get this right for a users collection and then forget it everywhere else: posts, orders, messages and uploads sit in top-level collections keyed by a random ID with an ownerId field that no rule ever reads.

For those collections the check moves from the path to the document. On reads and deletes, compare request.auth.uid with resource.data.ownerId, the field in the stored document. On creates, compare it with request.resource.data.ownerId, the field in the incoming document, and on updates check both so a user cannot hand a document to someone else. Firebase's docs describe this as allowing updates by the owner while preventing a change of ownership.

Firestore also reminds you that rules are not filters. A query for all posts will be rejected outright if any document it could return is denied by the rule, so your client queries must filter by ownerId too. That is a good forcing function: if the query has to say where('ownerId', '==', uid), the rule that enforces it is easy to write.

match /posts/{postId} {
  allow read, delete: if request.auth != null
    && resource.data.ownerId == request.auth.uid;
  allow create: if request.auth != null
    && request.resource.data.ownerId == request.auth.uid;
  allow update: if request.auth != null
    && resource.data.ownerId == request.auth.uid
    && request.resource.data.ownerId == resource.data.ownerId;
}

Cloud Storage has its own rules file and it is the one AI tools most often leave alone, because file uploads usually work on the first try. The default rules restrict reads and writes to authenticated users, but a generated project that needs to display avatars or attachments will often get allow read: if true on the whole bucket, sometimes with a comment saying it is temporary.

Public reads on a bucket of user uploads means anyone who can guess or enumerate a path can download it, including identity documents, selfies and screenshots people believed were private. Firebase's Storage docs show the correct shape: a path segment for the user ID, a write rule of request.auth.uid == userId, and a read rule of request.auth != null or a narrower ownership check. For an unauthenticated request, request.auth is null, so the comparison fails and the download is refused.

The same docs show validation on the way in. A rule such as request.resource.size < 5 * 1024 * 1024 && request.resource.contentType.matches('image/.*') stops a stranger from using your bucket as free hosting for arbitrary files and stops a user uploading a 2 GB video where you expected a profile picture.

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{fileName} {
      allow read: if request.auth != null
        && request.auth.uid == userId;
      allow write: if request.auth != null
        && request.auth.uid == userId
        && request.resource.size < 5 * 1024 * 1024
        && request.resource.contentType.matches('image/.*');
    }
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

A rule that only checks who is asking still lets that person write anything. Generated apps routinely store role, isAdmin, credits, price or status on the same document the user is allowed to edit. If the update rule does not inspect request.resource.data, a user can open the browser console and set their own role to admin or their order total to zero.

Firestore's rules-conditions guide draws the line clearly: resource.data is the document as it exists, and request.resource.data is the document as it will exist after the write. Good update rules compare the two. They pin the fields a user must not change to their existing values and they check types and ranges on the fields a user may change.

A practical habit: for every writable collection, list the fields the client is allowed to set, and write the rule so that only those fields can differ between resource.data and request.resource.data. Everything else, such as role, ownerId and createdAt, is either set by a trusted server with the Admin SDK, which bypasses rules, or is pinned in the rule.

match /profiles/{userId} {
  allow update: if request.auth != null
    && request.auth.uid == userId
    && request.resource.data.role == resource.data.role
    && request.resource.data.credits == resource.data.credits
    && request.resource.data.displayName is string
    && request.resource.data.displayName.size() <= 80;
}

Use this table to scan a generated rules file quickly. Each left-hand pattern is a real snippet you will find in AI-built projects, and the right-hand one is the shape Firebase's documentation recommends.

The Rules Playground lives in the Firebase console under the Rules tab of Firestore, Realtime Database or Storage. You choose a read or write, a path, and an authentication state such as unauthenticated or a specific user ID, then click Run and read the allowed or denied banner. It is the quickest way to answer "can a logged-out visitor read this document?" without writing code.

For anything you will maintain, Firebase recommends the Local Emulator Suite and the @firebase/rules-unit-testing library, which is the only supported way to mock auth in rules tests and never touches production resources. You create a test environment with initializeTestEnvironment, get an unauthenticatedContext and an authenticatedContext for a fake user, and wrap operations in assertSucceeds or assertFails. Run the suite with firebase emulators:exec so the emulators start and stop around it.

Write the negative tests first. The ones that catch generated rules are: unauthenticated read of a user document fails, user B reading user A's document fails, user A changing their own role fails, and an unauthenticated download from the Storage bucket fails. If those four pass in the emulator against the rules file you are about to deploy, you have closed the six mistakes above.

1. 1Install: npm install --save-dev @firebase/rules-unit-testing firebase-tools
2. 2Point firebase.json at your firestore.rules and storage.rules files.
3. 3Write tests with initializeTestEnvironment, unauthenticatedContext and authenticatedContext.
4. 4Run: firebase emulators:exec --only firestore,storage "npm test"
5. 5Deploy only after the negative tests pass: firebase deploy --only firestore:rules,storage

import { initializeTestEnvironment, assertFails, assertSucceeds } from "@firebase/rules-unit-testing";
import { doc, getDoc, setDoc } from "firebase/firestore";
import { readFileSync } from "fs";

const env = await initializeTestEnvironment({
  projectId: "demo-rules-test",
  firestore: { rules: readFileSync("firestore.rules", "utf8") },
});

const alice = env.authenticatedContext("alice").firestore();
const bob = env.authenticatedContext("bob").firestore();
const anon = env.unauthenticatedContext().firestore();

await assertSucceeds(setDoc(doc(alice, "users/alice"), { displayName: "Alice" }));
await assertFails(getDoc(doc(anon, "users/alice")));
await assertFails(getDoc(doc(bob, "users/alice")));
await assertFails(setDoc(doc(alice, "users/alice"), { role: "admin" }));

await env.cleanup();