Firebase Security Rules: The Gotcha That Will Burn You

Firestore security rules have a catch that trips up a lot of developers, including me.

The default deny-all rule that ships with most Firebase projects — allow read, write: if false; — blocks all client SDK access to any collection that doesn't have an explicit rule. Makes sense. But here's the part that gets people: the Admin SDK bypasses security rules entirely.

So when you're testing in your server-side code, everything works. When you're testing in the browser with the client SDK, you get silent failures, empty results, or permission-denied errors that don't always bubble up clearly.

The pattern that bites you

You add a new collection — let's say testimonials — and you seed it using the Admin SDK in a script. The data is in Firestore. Your server-side page that uses the Admin SDK reads it fine. You deploy. The page looks great.

Then someone builds the client-side version of that same feature. No data. No visible error. Just an empty array where there should be ten documents.

You spend an hour debugging the query before you check the rules.

The fix is simple, but you have to know to do it

Every time you add a collection, add a rule for it in the same PR. Period. Don't leave it for later. "Later" is when you're debugging a production issue at 11pm.

For public read / admin write:

match /testimonials/{docId} {
  allow read: if true;
  allow write: if request.auth != null && request.auth.token.admin == true;
}

For admin-only (like draft blog posts):

match /blogPosts/{docId} {
  allow read: if resource.data.isPublished == true
               || (request.auth != null && request.auth.token.admin == true);
  allow write: if request.auth != null && request.auth.token.admin == true;
}

Test your rules, don't assume

The Firebase emulator has a rules simulator. Use it. It will catch permission issues before they reach production. The Firebase console also has a Rules Playground if you want to spot-check without running the full emulator stack.

The Admin SDK is great for server-side data access — but its ability to bypass rules means it will not catch rules problems for you. Build the habit of writing rules alongside your collections, and you'll save yourself a lot of head-scratching.