Why security rules protect data in Firebase - Why It Works

Introduction

Security rules control who can see or change your data in Firebase. They keep your data safe from people who should not access it.

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

When you want to prevent anyone from deleting important information.

When you want to allow users to update only specific parts of their profile.

When you want to block access to data during certain times or conditions.

When you want to protect sensitive data like passwords or payment info.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Allow read/write only if user is authenticated
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    // Deny all other access
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

This file sets rules for Firestore database access.

rules_version: Specifies the version of rules syntax.

service cloud.firestore: Applies rules to Firestore.

match /users/{userId}: Matches documents in the users collection.

allow read, write: Allows reading and writing only if the user is logged in and accessing their own data.

match /{document=**}: Denies all other access to any other documents.

Commands

This command uploads and activates the security rules to your Firebase project to protect your data.

Terminal

firebase deploy --only firestore:rules

Expected Output

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



✔  firestore: rules



✔  Deploy complete!



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

→

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

Starts a local Firestore emulator to test your security 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 your app.

→

--only firestore - Runs only the Firestore emulator.

Runs tests on your Firestore security rules file to check if they work as expected.

Terminal

firebase firestore:rules:test --file firestore.rules

Expected Output

Running Firestore security rules tests...

All tests passed successfully.

Key Concept

If you remember nothing else from this pattern, remember: security rules control who can read or write your data to keep it safe.

Common Mistakes

Allowing read or write access without checking if the user is authenticated.

Anyone on the internet can see or change your data, risking privacy and data loss.

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

Writing rules that allow users to access other users' data.

Users can see or change data that does not belong to them, breaking privacy.

Use request.auth.uid == userId to restrict access to the user's own data.

Not testing rules before deploying.

Mistakes in rules can leave data unprotected or block legitimate access.

Use the Firebase emulator and rules test commands to verify rules work as intended.

Summary

Write security rules to allow only authenticated users to access their own data.

Deploy rules using the Firebase CLI to protect your database.

Test rules locally with the emulator to avoid mistakes before going live.

Practice

1. Why are Firebase security rules important for your app's data?

easy

A. They change the app's user interface based on user roles.

B. They speed up the app's performance by caching data.

C. They automatically back up your data to the cloud.

D. They control who can read or write data to keep it safe.

Solution

1. Step 1: Understand the role of security rules

   Security rules are designed to control access to data, deciding who can read or write it.

2. Step 2: Identify the main purpose of these rules

   The main goal is to keep data safe and private by restricting unauthorized access.

3. Final Answer:

   They control who can read or write data to keep it safe. -> Option D

4. Quick Check:

   Security rules protect data = They control who can read or write data to keep it safe. [OK]

Hint: Security rules control access to data, not app speed or UI [OK]

Common Mistakes:

• Confusing security rules with performance features
• Thinking rules change app design or backup data
• Assuming rules automatically fix bugs

2. Which of the following is the correct way to write a Firebase security rule that allows only authenticated users to read data?

easy

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

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

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

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

Solution

1. Step 1: Recall Firebase rule syntax for authentication

   Firebase uses request.auth != null to check if a user is signed in.

2. Step 2: Compare options to correct syntax

   Only allow read: if request.auth != null; uses the correct Firebase syntax for authenticated access.

3. Final Answer:

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

4. Quick Check:

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

Hint: Use 'request.auth != null' to check signed-in users [OK]

Common Mistakes:

• Using incorrect variable names like user.authenticated
• Confusing request.user with request.auth
• Missing the 'if' keyword in rules

3. Given this Firebase rule snippet:

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

What happens if a user tries to write data where their UID does not match ownerId?

medium

A. The write is allowed because the rule only checks if user is authenticated.

B. The write is allowed only if the user is an admin.

C. The write is denied because the user's UID does not match the ownerId.

D. The write is denied only if the data is empty.

Solution

1. Step 1: Understand the rule condition

   The rule allows writes only if the user's UID matches the ownerId in the data.

2. Step 2: Analyze the user's UID mismatch

   If the user's UID does not match ownerId, the condition fails, so the write is denied.

3. Final Answer:

   The write is denied because the user's UID does not match the ownerId. -> Option C

4. Quick Check:

   UID mismatch denies write = The write is denied because the user's UID does not match the ownerId. [OK]

Hint: UID must match ownerId to allow write [OK]

Common Mistakes:

• Assuming any authenticated user can write
• Thinking admin rights are checked here
• Ignoring the exact match condition

4. You wrote this Firebase rule:

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

But users report they cannot write their own data. What is the likely problem?

medium

A. The rule is missing a semicolon at the end.

B. The rule should use request.resource.data.ownerId instead of resource.data.ownerId.

C. The rule should allow all users to write without conditions.

D. The rule should check request.auth.email instead of UID.

Solution

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

   resource.data refers to existing data, while request.resource.data refers to new data being written.

2. Step 2: Identify the correct field to check ownerId

   To verify the ownerId in the data being written, use request.resource.data.ownerId.

3. Final Answer:

   The rule should use request.resource.data.ownerId instead of resource.data.ownerId. -> Option B

4. Quick Check:

   Check new data with request.resource = The rule should use request.resource.data.ownerId instead of resource.data.ownerId. [OK]

Hint: Use request.resource for new data checks, not resource [OK]

Common Mistakes:

• Confusing resource with request.resource
• Ignoring the need to check new data fields
• Removing conditions to fix access issues

5. You want to protect a collection so that users can only read their own documents and write only if they are the owner. Which rule correctly enforces this?

hard

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

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

C. allow read, write: if request.auth != null;

D. allow read, write: if request.auth.uid == resource.data.ownerId && request.auth.uid == request.resource.data.ownerId;

Solution

1. Step 1: Understand read and write conditions

   Reads check existing data's ownerId with resource.data.ownerId. Writes check new data's ownerId with request.resource.data.ownerId.

2. Step 2: Match conditions to options

   allow read: if request.auth.uid == resource.data.ownerId; allow write: if request.auth.uid == request.resource.data.ownerId; correctly separates read and write checks using the right references for existing and new data.

3. Final Answer:

   allow read: if request.auth.uid == resource.data.ownerId; allow write: if request.auth.uid == request.resource.data.ownerId; -> Option A

4. Quick Check:

   Read uses resource, write uses request.resource = allow read: if request.auth.uid == resource.data.ownerId; allow write: if request.auth.uid == request.resource.data.ownerId; [OK]

Hint: Read checks resource, write checks request.resource for ownerId [OK]

Common Mistakes:

• Using same data reference for read and write
• Allowing all authenticated users to write
• Not checking ownership on writes