Common rule patterns in Firebase - Step-by-Step Execution

Process Flow - Common rule patterns

Start Request

↓

Match Request Path

↓

Check Rule Conditions

↓

Allow

↓

End Request

A request comes in, matches a path, checks conditions, then allows or denies access.

Execution Sample

Firebase

match /documents/{docId} {
  allow read: if request.auth != null;
  allow write: if request.auth.uid == resource.data.owner;
}

This rule allows reading if the user is logged in, and writing only if the user owns the document.

Process Table

Step	Request Path	Condition Checked	Condition Result	Access Decision
1	/documents/abc123	request.auth != null	true	Allow read
2	/documents/abc123	request.auth.uid == resource.data.owner	false	Deny write
3	/documents/abc123	request.auth != null	false	Deny read
4	/documents/abc123	request.auth.uid == resource.data.owner	true	Allow write

💡 Access decision made based on condition results for read or write.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
request.auth	null or object	object (logged in)	object (logged in)	null	object (logged in)
request.auth.uid	undefined	user123	user123	undefined	user123
resource.data.owner	user123	user123	user456	user123	user123

Key Moments - 3 Insights

Why does a read request get denied even if the user is logged in?

If request.auth is null (user not logged in), the condition 'request.auth != null' fails, so read access is denied as shown in step 3 of the execution table.

Why can a user read but not write the same document?

Read requires only that the user is logged in (request.auth != null), but write requires the user ID to match the document owner. If they don't match, write is denied (step 2).

What happens if the request path does not match any rule?

No matching rule means no access is granted, so the request is denied by default.

Visual Quiz - 3 Questions

Look at the execution table, what is the access decision at step 2?

A Allow write

B Deny write

C Allow read

D Deny read

💡 Hint

Check the 'Access Decision' column in row 2 of the execution table.

At which step does the condition 'request.auth != null' evaluate to false?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Condition Result' column for 'request.auth != null' in the execution table.

If the resource.data.owner changes to 'user123' at step 2, what would happen to the write access decision?

A Write would be allowed

B Write would be denied

C Read would be denied

D No change

💡 Hint

Compare 'request.auth.uid' and 'resource.data.owner' values in variable_tracker after step 2.

Concept Snapshot

Firebase rules check requests by matching paths and conditions.
Use 'allow' with conditions like 'request.auth != null' to control access.
Read and write can have different conditions.
If no rule matches or condition fails, access is denied.
Rules protect data by verifying user identity and ownership.

Full Transcript

Firebase security rules work by matching the incoming request path to defined rules. Then, each rule checks conditions such as whether the user is logged in or owns the data. If the condition is true, access is allowed; otherwise, it is denied. For example, a read request is allowed if the user is authenticated, while a write request requires the user to be the owner of the document. If no rules match or conditions fail, access is denied by default. This ensures data is protected and only accessible to authorized users.

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