Enforce User-Based Data Isolation in Firestore with Security Rules

The Problem: Preventing Unauthorized Access to User Data

When building a multi‑user application with Firestore, you need to ensure users can only access their own data. Without proper security rules, any authenticated user could potentially read or modify another user’s documents, creating a serious data isolation vulnerability.

Prerequisites

• Firestore database in production mode
• At least one authenticated user with a known UID
• Basic understanding of Firestore document structure
• Firebase CLI installed for local testing

Core Rule Pattern: UID‑Based Document Isolation

The most common pattern for user isolation is to restrict access so users can only interact with documents where the document ID matches their authentication UID. This works well for user profile documents or single‑document‑per‑user data.

Start with this basic rule structure in your firestore.rules file:

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

Adding Data Validation to Write Operations

Beyond access control, you should validate data structure before allowing writes. This prevents malformed data and ensures required fields exist:

match /users/{userId} {
  allow read: if request.auth != null && request.auth.uid == userId;
  
  allow create: if request.auth != null 
    && request.auth.uid == userId 
    && request.resource.data.keys().hasAll(['name', 'email', 'createdAt'])
    && request.resource.data.email is string
    && request.resource.data.createdAt is timestamp;
  
  allow update, delete: if request.auth != null && request.auth.uid == userId;
}

Handling Collection‑Based User Data

If user data is stored in a collection where each document represents a user’s data item (not one document per user), you need to reference the user ID within the document data:

match /userItems/{itemId} {
  allow read, write: if request.auth != null 
    && request.auth.uid == resource.data.ownerId;
}

This pattern requires that every document in userItems contains an ownerId field matching the creator’s UID.

Cross‑Collection Permission Checks

For more complex scenarios where you need to verify permissions stored elsewhere, use get() to read other documents within rules:

match /posts/{postId} {
  allow read: if request.auth != null 
    && (request.auth.uid == resource.data.authorId 
    || get(/databases/$(database)/documents/users/$(request.auth.uid)).data.canReadPosts == true);
}

Warning: Each get() call counts as a document read against your quota.

Testing Rules Locally

Use the Firebase Local Emulator Suite to test rules without touching production data:

1. Start the emulator: firebase emulators:start --only firestore
2. In a separate terminal, run rule unit tests:

firebase emulators:exec "npm test"

Verification Checklist

• Attempt to read a document with a different user’s UID – should return permission denied
• Try creating a document without required fields – should be rejected
• Verify queries work correctly when filtering by authenticated user’s data
• Test that the rules deploy successfully: firebase deploy --only firestore:rules

Common Pitfalls to Avoid

• Rules are not filters: A query like db.collection('users').get() will fail entirely if you’re not authorized for any documents, rather than returning only authorized ones.
• Overly broad rules: Never use allow read, write: if true; in production – this exposes your entire database publicly.
• Missing validation: Always validate data structure in rules to prevent injection of unexpected fields or types.

Rollback Options

If rules cause issues, you can quickly revert by:

1. Restoring a previous rules version from version control
2. Deploying the previous rules: git checkout HEAD~1 -- firestore.rules && firebase deploy --only firestore:rules
3. Using the Firebase console to view and restore rule history