Common rule patterns in Firebase - Commands & Configuration

Introduction

Firebase rules control who can read or write data in your database. They help keep your data safe by setting clear permissions.

When you want only logged-in users to read or write their own data.

When you want to allow public read access but restrict writes to admins.

When you want to validate data before it is saved to the database.

When you want to organize rules by user roles like admin, editor, or viewer.

When you want to prevent users from deleting data they do not own.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Allow users to read and write their own profile
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }

    // Allow anyone to read public posts, but only owners can write
    match /posts/{postId} {
      allow read: if true;
      allow write: if request.auth != null && request.auth.uid == request.resource.data.ownerId;
    }

    // Admins can read and write everything
    match /{document=**} {
      allow read, write: if request.auth != null && request.auth.token.admin == true;
    }
  }
}

This file sets rules for Firestore database access.

• users/{userId}: Users can only access their own profile data.
• posts/{postId}: Anyone can read posts, but only the owner can write.
• {document=**}: Admin users can read and write all data.

Commands

This command uploads and activates your Firestore security rules to protect your database.

Terminal

firebase deploy --only firestore:rules

Expected Output

=== Deploying to 'my-firebase-project'...



i  deploying firestore

✔  firestore: rules updated successfully



✔  Deploy complete!

→

--only firestore:rules - Deploys only the Firestore security rules without affecting other Firebase services.

Starts the local Firestore emulator so you can test your rules safely on your computer.

Terminal

firebase emulators:start --only firestore

Expected Output

i  emulators: Starting emulators: firestore

✔  firestore: Emulator started at http://localhost:8080



All emulators started, it is now safe to connect.

→

--only firestore - Runs only the Firestore emulator without starting other Firebase emulators.

Runs tests against your Firestore rules using a test file to check if permissions work as expected.

Terminal

firebase firestore:rules:test --rules=firestore.rules --file=tests/read_write_test.json

Expected Output

PASS 3 tests, FAIL 0 tests

All tests passed successfully.

→

--rules - Specifies the rules file to test.

→

--file - Specifies the test cases file.

Key Concept

If you remember nothing else from this pattern, remember: Firebase rules protect your data by clearly defining who can read or write each part.

Common Mistakes

Allowing write access without checking user identity.

Anyone could change or delete data, causing security risks.

Always check that request.auth.uid matches the data owner before allowing writes.

Using 'allow read: if true;' on sensitive data.

This makes private data visible to everyone.

Restrict read access to authenticated users or specific roles.

Not deploying updated rules after changes.

Your database remains unprotected or uses old rules.

Run 'firebase deploy --only firestore:rules' after editing rules.

Summary

Write rules to control who can read or write each part of your Firestore database.

Deploy rules using 'firebase deploy --only firestore:rules' to activate them.

Test rules locally with the Firestore emulator before deploying to production.

Practice

1. What is the main purpose of Firebase security rules in a database?

easy

A. To control who can read or write data

B. To speed up database queries

C. To store user passwords securely

D. To backup data automatically

Solution

1. Step 1: Understand Firebase security rules role

   Firebase security rules define who can access or change data in your database.

2. Step 2: Identify the main function

   The main function is to control read and write access to protect data.

3. Final Answer:

   To control who can read or write data -> Option A

4. Quick Check:

   Security rules = access control [OK]

Hint: Rules control data access permissions quickly [OK]

Common Mistakes:

• Confusing rules with data backup
• Thinking rules speed up queries
• Assuming rules store passwords

2. Which of the following is the correct syntax to allow only authenticated users to read data in Firebase rules?

easy

A. allow read: if request.auth != null;

B. allow read: if user.loggedIn == true;

C. allow read: if auth.user == true;

D. allow read: if request.user != null;

Solution

1. Step 1: Identify correct Firebase auth syntax

   Firebase uses request.auth to check if a user is authenticated.

2. Step 2: Match syntax to allow read only if authenticated

   The correct condition is request.auth != null meaning user is logged in.

3. Final Answer:

   allow read: if request.auth != null; -> Option A

4. Quick Check:

   request.auth != null means user logged in [OK]

Hint: Use request.auth to check user authentication [OK]

Common Mistakes:

• Using incorrect variable names like user.loggedIn
• Checking auth.user instead of request.auth
• Confusing request.user with request.auth

3. Given this Firebase rule snippet:

allow write: if request.auth.uid == resource.data.ownerId;

What does this rule enforce?

medium

A. No one can write to the data

B. Only the owner of the data can write to it

C. Anyone can write if authenticated

D. Only admins can write to the data

Solution

1. Step 1: Understand the condition in the rule

   The rule checks if the user's ID matches the ownerId stored in the data.

2. Step 2: Interpret the effect of the condition

   This means only the user who owns the data (ownerId) can write to it.

3. Final Answer:

   Only the owner of the data can write to it -> Option B

4. Quick Check:

   request.auth.uid == resource.data.ownerId means owner only [OK]

Hint: Match request.auth.uid with data ownerId to allow write [OK]

Common Mistakes:

• Assuming all authenticated users can write
• Thinking admins are required
• Believing no one can write

4. Identify the error in this Firebase rule snippet:

allow read: if request.auth.uid = resource.data.ownerId;

medium

A. request.auth.uid is not a valid property

B. Missing semicolon at the end of the line

C. Using single equals (=) instead of double equals (==) for comparison

D. resource.data.ownerId cannot be used in rules

Solution

1. Step 1: Check the comparison operator used

   The rule uses a single equals sign (=) which is assignment, not comparison.

2. Step 2: Correct operator for comparison in Firebase rules

   Firebase rules require double equals (==) to compare values.

3. Final Answer:

   Using single equals (=) instead of double equals (==) for comparison -> Option C

4. Quick Check:

   Use == for comparison, not = [OK]

Hint: Use == to compare values in rules, not = [OK]

Common Mistakes:

• Confusing assignment (=) with comparison (==)
• Thinking semicolon is mandatory
• Believing request.auth.uid is invalid

5. You want to allow users to update their own profile but prevent them from changing their user ID. Which Firebase rule pattern correctly enforces this?

hard

A. allow update: if request.auth.uid == request.resource.data.userId;

B. allow update: if request.resource.data.userId == null;

C. allow update: if request.auth.uid != resource.data.userId;

D. allow update: if request.auth.uid == resource.data.userId && request.resource.data.userId == resource.data.userId;

Solution

1. Step 1: Ensure user can update only their own profile

   The rule must check that the authenticated user matches the existing userId in data.

2. Step 2: Prevent changing the userId field

   Check that the new data's userId matches the old data's userId to prevent changes.

3. Final Answer:

   allow update: if request.auth.uid == resource.data.userId && request.resource.data.userId == resource.data.userId; -> Option D

4. Quick Check:

   Match auth.uid and keep userId unchanged [OK]

Hint: Check auth.uid matches and userId stays same [OK]

Common Mistakes:

• Allowing userId to be changed
• Not verifying user owns the profile
• Using != instead of == for ownership check