Firebase Firestore is one of the most popular cloud databases for mobile apps, web applications, and Unity games. It provides real-time synchronization, scalability, and seamless integration with Firebase services.
However, many developers unknowingly leave their Firestore databases exposed due to poorly configured security rules. A single mistake can allow unauthorized users to read, modify, or delete sensitive data.
Firestore Security Rules are designed to prevent these risks by controlling who can access your database and what actions they can perform.
In this guide, you’ll learn how Firestore Security Rules work, discover common mistakes, and implement best practices to keep your Firebase project secure in 2026.
Why Firestore Security Rules Are Important
Every Firestore request is checked against your security rules before it reaches the database.
Without proper rules:
- User data can be exposed.
- Attackers can modify records.
- Entire collections may be deleted.
- Malicious users can abuse database resources.
Security Rules act as a protective layer between your application and Firestore.
Even if someone reverse-engineers your app, correctly configured rules prevent unauthorized access.
Understanding Firestore Security Rules
Firestore Security Rules are written using a rule-based language provided by Firebase.
They define:
- Who can read data
- Who can create documents
- Who can update records
- Who can delete data
- What fields are allowed
Every database request is validated against these rules before execution.
The Dangerous Testing Rule
Many developers start with Firebase’s testing mode:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true;
}
}
}
This rule allows anyone on the internet to access your Firestore database.
It should only be used during temporary development and never in production.
Rule #1: Require User Authentication
The first step toward securing Firestore is requiring users to sign in.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
This rule ensures only authenticated users can interact with the database.
Anonymous visitors will be blocked automatically.
Rule #2: Restrict Users to Their Own Documents
Authentication alone is not enough.
Suppose your database structure looks like:
users
├── uid123
├── uid456
└── uid789
Without ownership checks, any authenticated user could potentially access another user’s data.
A secure rule would be:
match /users/{userId} {
allow read, write:
if request.auth != null
&& request.auth.uid == userId;
}
Now users can only access their own documents.
Rule #3: Protect Admin Collections
Some collections should never be accessible to regular users.
For example:
admins
settings
payments
analytics
You can completely block access:
match /admins/{document} {
allow read, write: if false;
}
This prevents unauthorized access even if users discover the collection path.
Rule #4: Validate Incoming Data
Firestore Rules can verify the structure and content of incoming data.
Example:
allow write: if
request.resource.data.name is string
&& request.resource.data.name.size() <= 50;
This ensures:
- The name field is a string.
- The name is not excessively long.
Data validation helps prevent malicious or invalid content.
Rule #5: Prevent Users from Changing Protected Fields
Imagine storing user roles:
{
"name": "John",
"role": "user"
}
Without protection, users could attempt:
{
"name": "John",
"role": "admin"
}
To prevent this:
allow update: if
request.resource.data.role ==
resource.data.role;
The role field must remain unchanged.
Rule #6: Use Firebase Custom Claims for Admin Access
Administrative actions should never rely on client-side checks.
Instead, use Firebase Custom Claims.
Example:
allow write: if
request.auth.token.admin == true;
Only authenticated users with the admin claim can perform protected actions.
Common Firestore Security Mistakes
Mistake #1: Leaving Test Rules Enabled
allow read, write: if true;
This is the most common and dangerous mistake.
Mistake #2: Trusting Client-Side Validation
Attackers can modify application code and bypass UI restrictions.
Always enforce validation in Firestore Rules.
Mistake #3: Missing Ownership Checks
Authentication without ownership verification often leads to data exposure.
Mistake #4: Ignoring Rule Testing
Rules should be tested before every production release.
Testing Firestore Rules
Firebase provides the Emulator Suite for testing security rules locally.
Benefits include:
- Testing without affecting production data.
- Simulating multiple users.
- Verifying permissions.
- Detecting security flaws early.
Testing should be a mandatory step before deployment.
Secure Firestore Rules Example
The following example demonstrates a secure user profile collection:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow create:
if request.auth != null;
allow read:
if request.auth.uid == userId;
allow update:
if request.auth.uid == userId;
allow delete:
if false;
}
}
}
Features:
- Authentication required.
- Users access only their own data.
- Deletion disabled.
- Improved security.
Firestore Security for Unity Games
Unity developers commonly store:
- Player profiles
- Cloud save data
- Leaderboards
- Inventory data
- Game progression
Example structure:
players
├── uid123
├── uid456
Recommended rule:
match /players/{playerId} {
allow read, write:
if request.auth.uid == playerId;
}
This prevents players from modifying other users’ save data.
Firestore Security Checklist
Before publishing your app:
- Enable Firebase Authentication.
- Remove testing rules.
- Implement ownership checks.
- Validate incoming data.
- Protect admin collections.
- Use Custom Claims when necessary.
- Test rules using Emulator Suite.
- Review all collections and permissions.
Following this checklist greatly reduces security risks.
Frequently Asked Questions
Can Firestore Rules stop hackers?
Properly configured rules prevent unauthorized access because they are enforced server-side by Firebase.
Are Firestore Rules enough for security?
They provide strong protection but should be combined with secure authentication and backend validation when required.
Should I use Custom Claims?
Yes. Custom Claims are the recommended method for implementing admin-only access.
Can users bypass Firestore Rules?
No. Rules are enforced by Firebase servers and cannot be bypassed through client-side modifications.
What is the biggest Firestore security mistake?
Leaving:
allow read, write: if true;
enabled in production.
Final Verdict
Firebase Firestore Security Rules are one of the most important components of any Firebase-powered application.
A properly secured Firestore database should:
- Require authentication.
- Restrict users to their own data.
- Validate incoming content.
- Protect sensitive collections.
- Use admin-only access controls.
- Be thoroughly tested before release.
Investing time in Firestore security today can prevent data leaks, unauthorized access, and serious production issues in the future.
For most developers, implementing strong security rules is one of the highest-value improvements they can make to a Firebase project.
