Menu

I Broke My Own Firestore Rules in Production Once. Now the Emulator Catches It First.
πŸ“°

I Broke My Own Firestore Rules in Production Once. Now the Emulator Catches It First.

DEV Community: databaseΒ·Purvansh BhattΒ·about 15 hours ago
#lqb1GFCP
#devtodatabase#devto#dev#rules#test
Reading 0:00
15s threshold

The deploy that taught me the lesson

I changed one line in my Firestore security rules. It looked safe β€” I was tightening a read rule on a collection so only the owning tenant could read its documents. I deployed it, moved on, and found out later that a legitimate read path had started failing. Nothing dramatic broke in a way that paged me. It just quietly stopped working for a real user flow, and I only caught it because I happened to test that flow by hand afterward.

That is the worst kind of bug: a security change that fails closed in the wrong place, silently, with no test to catch it. I had unit tests for my API. I had tests for my scoring logic. I had no tests for the rules that decide who can read and write my data. The rules were the one layer I was editing by feel and verifying by hope.

So I fixed it the boring way: I put my Firestore rules under test in CI, using the Firebase Emulator Suite, and made the deploy pipeline refuse to ship rules that fail those tests.…

Continue reading β€” create a free account

Join HashtagPLUS to read full articles, follow hashtags, vote, and join the conversation.