Firebase Firestore: why 'allow read, write: if request.auth != null' is not security
> TL;DR: The basic Firestore authentication rule doesn't protect your data. Here's why and how to fix it.
The false sense of security
The rule allow read, write: if request.auth != null is the most common Firestore configuration. It seems secure. In reality, it allows ANY authenticated user to read and modify ALL other users' data.
The fix
Replace with: allow read, write: if request.auth.uid == resource.data.userId
What we find
70% of Firebase applications we audit use this basic rule.
Key Takeaways
Building software? CleanIssue performs security audits for your product in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
CVE-2026-32541: Next.js middleware bypass — analysis and fix
A critical vulnerability in Next.js middleware allowed authentication bypass. Technical analysis of the flaw and fix guide for SaaS vendors.
Password reset: the 7 mistakes that open up your accounts
The "forgot password" flow is attackers' favorite way into SaaS accounts: predictable tokens, links that never expire, host header injection. The 7 mistakes we find most often in audits.
WordPress REST API: 7 dangerous endpoints enabled by default
Your WordPress exposes sensitive data via REST API without you knowing. Here are 7 endpoints to check now.
Sources
Editorial analysis based on official vendor, project, and regulator documentation.
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.