Authentication-based rules in Firebase - Commands & Configuration

Introduction

When you store data in Firebase, you want to control who can read or write it. Authentication-based rules let you allow only signed-in users to access certain data, keeping your app safe and private.

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

When you want to prevent anonymous users from writing data to your database.

When you want to allow users to update only their own records.

When you want to restrict access to certain parts of your database based on user login status.

When you want to secure your app data without building a separate backend.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Allow read/write only if user is signed in
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

This file sets rules for Firestore database.

rules_version specifies the rules syntax version.

service cloud.firestore targets Firestore.

match /users/{userId} applies rules to user documents.

allow read, write permits these actions only if the user is signed in (request.auth != null) and their user ID matches the document ID (request.auth.uid == userId).

Commands

This command uploads and activates your Firestore security rules to Firebase, enforcing your authentication-based access control.

Terminal

firebase deploy --only firestore:rules

Expected Output

=== Deploying to 'your-project-id'...



✔  Deploy complete!



Project Console: https://console.firebase.google.com/project/your-project-id/overview



Firestore rules deployed successfully.

→

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

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

Terminal

firebase emulators:start --only firestore

Expected Output

i  emulators: Starting emulators: firestore

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



⚠  firestore: Authentication is not enforced in the emulator.

→

--only firestore - Starts only the Firestore emulator.

Runs tests against your Firestore rules using a test file to verify that authentication-based access works as expected.

Terminal

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

Expected Output

Running Firestore rules tests...

All tests passed successfully.

Key Concept

If you remember nothing else from this pattern, remember: authentication-based rules let only signed-in users access their own data securely.

Common Mistakes

Allowing read or write without checking if the user is signed in.

This lets anyone, even without login, access or change your data, risking security.

Always check that request.auth is not null before allowing access.

Not matching the user ID in the rule to the authenticated user's ID.

Users could read or write other users' data, breaking privacy.

Use request.auth.uid == userId to ensure users access only their own documents.

Deploying rules without testing them locally first.

Mistakes in rules can lock out users or expose data unintentionally.

Use the Firebase emulator to test rules before deploying.

Summary

Write Firestore rules that check if a user is signed in using request.auth != null.

Match document IDs to the authenticated user's ID to restrict access to their own data.

Deploy rules with 'firebase deploy --only firestore:rules' and test locally with the emulator.

Practice

1. What does the Firebase rule condition request.auth != null check for?

easy

A. If the request is from a mobile device

B. If the user has admin privileges

C. If the user is signed in

D. If the database is empty

Solution

1. Step 1: Understand the meaning of request.auth

   request.auth holds authentication info if a user is signed in; otherwise, it is null.

2. Step 2: Interpret the condition request.auth != null

   This condition is true only when a user is signed in, meaning authentication info exists.

3. Final Answer:

   If the user is signed in -> Option C

4. Quick Check:

   Authentication check = user signed in [OK]

Hint: Check if request.auth is not null to confirm user login [OK]

Common Mistakes:

• Thinking it checks for admin rights
• Assuming it checks device type
• Confusing with database content check

2. Which of the following is the correct Firebase rule syntax to allow read access only to authenticated users?

easy

A. allow read: if request.auth == true;

B. allow read: if request.auth == null;

C. allow read: if request.auth.id == null;

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

Solution

1. Step 1: Identify the correct condition for authenticated users

   The condition request.auth != null means the user is signed in.

2. Step 2: Match the syntax with the correct condition

   allow read: if request.auth != null; uses allow read: if request.auth != null; which correctly allows reads only for signed-in users.

3. Final Answer:

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

4. Quick Check:

   Correct syntax for auth check = allow read: if request.auth != null; [OK]

Hint: Use != null to allow only signed-in users [OK]

Common Mistakes:

• Using == null which allows unauthenticated users
• Checking request.auth.id instead of request.auth
• Using boolean true instead of null check

3. Given this Firebase rule snippet:

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

What happens if a signed-in user tries to read data where ownerId is different from their uid?

medium

A. Read access is denied

B. Read access is granted only if user is admin

C. Read access is granted

D. Read access causes a syntax error

Solution

1. Step 1: Analyze the rule condition

   The rule requires the user to be signed in and their user ID (uid) to match the data's ownerId.

2. Step 2: Evaluate the scenario where uid differs from ownerId

   Since the IDs do not match, the condition fails, so access is denied.

3. Final Answer:

   Read access is denied -> Option A

4. Quick Check:

   User ID match required = access denied if no match [OK]

Hint: User ID must match ownerId for access [OK]

Common Mistakes:

• Assuming any signed-in user can read
• Thinking admin rights are checked here
• Confusing syntax error with logic denial

4. Identify the error in this Firebase rule:

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

medium

A. Missing check for request.auth != null

B. Using single equals (=) instead of double equals (==)

C. Incorrect field name 'ownerId'

D. No error, rule is correct

Solution

1. Step 1: Check the comparison operator

   The rule uses a single equals = which is an assignment, not a comparison.

2. Step 2: Correct operator usage in Firebase rules

   Firebase rules require double equals == for equality checks.

3. Final Answer:

   Using single equals (=) instead of double equals (==) -> Option B

4. Quick Check:

   Use == for comparisons, not = [OK]

Hint: Use == for equality, not = [OK]

Common Mistakes:

• Confusing assignment (=) with comparison (==)
• Ignoring null check for request.auth
• Assuming field names cause error

5. You want to write a Firebase rule that allows users to update their own profile only if they are signed in and the profile's userId matches their uid. Which rule correctly implements this?

hard

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

B. allow update: if request.auth != null && request.auth.uid == request.resource.data.userId;

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

D. allow update: if request.auth != null && request.auth.uid == resource.data.ownerId;

Solution

1. Step 1: Understand the difference between resource.data and request.resource.data

   resource.data is the existing data; request.resource.data is the new data being written.

2. Step 2: Match user ID with existing data's userId during update

   To allow update only if the profile's existing userId matches the user's uid, compare request.auth.uid with resource.data.userId.

3. Step 3: Verify the condition

   allow update: if request.auth != null && request.auth.uid == resource.data.userId; correctly checks the user is signed in and owns the existing profile.

4. Final Answer:

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

5. Quick Check:

   Check existing data userId matches auth.uid for update [OK]

Hint: Use resource.data for existing ownership checks [OK]

Common Mistakes:

• Using request.resource.data (new data) instead of resource.data (existing data)
• Allowing updates without authentication
• Using wrong field names for user ID