Fix: Firestore 'Missing or Insufficient Permissions'

The Problem

If Firestore throws Missing or insufficient permissions, your security rules are blocking the read or write your app just tried to make. This is not a bug in Firestore — it is Firestore doing its job and rejecting a request that does not satisfy your rules. The fix is almost always to update your firestore.rules file or the authentication state of the request.

Why It Happens

There are four common causes behind the missing or insufficient permissions error:

Default locked rules. New Firestore databases start in "locked mode," where every read and write is denied by default until you explicitly allow it. request.auth is null. If the user is not signed in when the request fires, request.auth is null, so any rule that checks request.auth != null or request.auth.uid will fail. Rules don't match the path. A rule written for /users/{userId} will not apply to /users/{userId}/orders/{orderId} unless you explicitly nest a matching rule. Test mode expired. Firestore's "test mode" rules only allow open access for 30 days, then automatically flip to deny-all.

The Fix

1. Check your current security rules

Open the Firebase console under Firestore Database > Rules, or your local firestore.rules file. A locked default looks like this:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

That if false blocks everything, which is exactly what produces missing or insufficient permissions on every request.

2. Write rules scoped to authenticated users

Replace the blanket deny with rules that check request.auth and match your actual data model:

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

This allows a signed-in user to read and write only their own /users/{userId} document, using request.auth.uid to compare against the document ID.

3. Confirm the user is actually signed in

If request.auth is null in your rules, the client is querying before authentication resolves. Guard your query with an auth state check:

import { onAuthStateChanged } from 'firebase/auth';
import { auth, db } from './firebase';
import { doc, getDoc } from 'firebase/firestore';
onAuthStateChanged(auth, async (user) => {
  if (!user) return; // avoid querying while unauthenticated
  const snap = await getDoc(doc(db, 'users', user.uid));
  console.log(snap.data());
});

4. Match rules to nested collection paths

Rules do not cascade automatically. If your data lives in a subcollection, add a nested match:

match /users/{userId} {
  allow read, write: if request.auth.uid == userId;
  match /orders/{orderId} {
    allow read, write: if request.auth.uid == userId;
  }
}

5. Watch for expired test mode

If your rules still say allow read, write: if request.time < timestamp.date(2026, 1, 1);, the date has likely passed. Replace it with production rules like the ones above instead of extending the deadline.

How to Prevent It

• Never ship to production with test-mode rules
• Always scope rules with request.auth.uid instead of leaving collections open
• Use the Firestore Rules Playground in the console to simulate requests before deploying
• Write nested match blocks for every subcollection you query
• Add rules unit tests with the Firebase Emulator Suite so permission changes are caught in CI

Frequently Asked Questions

Why does Firestore say missing or insufficient permissions even though I'm logged in?

Your rules may not reference request.auth correctly, or the path in your query doesn't match a rule you've defined. Log request.auth in the Rules Playground to confirm it isn't null.

Does test mode expire automatically?

Yes. Firestore test mode rules include a hardcoded expiration date and switch to deny-all 30 days after the database is created.

Can I allow read access to everyone but restrict writes?

Yes, split the conditions: allow read: if true; allow write: if request.auth != null; — though open reads are rarely appropriate for production data.

How do I debug which rule is blocking a specific request?

Use the Firestore Rules Playground in the Firebase console, or enable debug logging in the Firebase Emulator Suite to see exactly which rule evaluated to false.

Need Help?

If your security rules keep breaking as your data model grows, our team can audit and rebuild them properly. Explore our development services or get in touch.