Read and write permissions in Firebase - Step-by-Step Execution

Process Flow - Read and write permissions

Client Request

↓

Check Read Permission?

No→Deny Read

Yes↓

Allow Read

↓

Check Write Permission?

No→Deny Write

Yes↓

Allow Write

When a client tries to read or write data, Firebase checks the rules for read and write permissions separately and allows or denies the action accordingly.

Execution Sample

Firebase

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /messages/{messageId} {
      allow read: if true;
      allow write: if false;
    }
  }
}

This Firebase rule allows anyone to read messages but denies all write attempts.

Process Table

Step	Action	Permission Checked	Condition	Result	Effect
1	Client requests to read /messages/123	read	true	allowed	Client can read the message
2	Client requests to write /messages/123	write	false	denied	Client cannot write the message
3	Client requests to write /messages/456	write	false	denied	Client cannot write the message
4	Client requests to read /messages/456	read	true	allowed	Client can read the message
5	No more requests	-	-	-	Execution ends

💡 All requests processed; reads allowed, writes denied by rules

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
read_permission	undefined	true	true	true	true	true
write_permission	undefined	false	false	false	false	false

Key Moments - 2 Insights

Why can the client read messages but not write them?

Because the read permission condition is 'true' (always allows), but the write permission condition is 'false' (always denies), as shown in execution_table rows 1 and 2.

Does Firebase check read and write permissions together or separately?

Firebase checks read and write permissions separately for each request type, as seen in the flow and execution_table where read and write are evaluated independently.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of the client trying to write to /messages/123?

A Allowed

B Pending

C Denied

D Not checked

💡 Hint

Check row 2 in the execution_table where write permission is false and result is denied.

At which step does the client successfully read a message?

A Step 1

B Step 3

C Step 2

D Step 5

💡 Hint

Look at execution_table row 1 where read is allowed.

If the write permission condition changed to 'true', what would happen at step 2?

A Write would be denied

B Write would be allowed

C Read would be denied

D No change

💡 Hint

Refer to variable_tracker write_permission changing from false to true would allow writes.

Concept Snapshot

Firebase security rules control read and write access.
Use 'allow read: if condition;' and 'allow write: if condition;'.
Read and write permissions are checked separately.
True means allow, false means deny.
Rules apply to specific document paths.

Full Transcript

Firebase security rules decide if a client can read or write data. When a client requests to read or write, Firebase checks the rules for that action. If the condition is true, the action is allowed; if false, it is denied. In the example, reading messages is always allowed, but writing is always denied. This means clients can see messages but cannot change them. The checks for read and write happen separately for each request. Changing the write condition to true would allow clients to write messages.

Practice

1. What is the main purpose of Firebase read and write permissions?

easy

A. To control who can view or change data in the database

B. To speed up data retrieval from the database

C. To backup data automatically

D. To create new database tables

Solution

1. Step 1: Understand permission roles

   Read and write permissions define who can access or modify data.

2. Step 2: Identify the purpose

   They protect data by controlling access, not by speeding up or backing up data.

3. Final Answer:

   To control who can view or change data in the database -> Option A

4. Quick Check:

   Permissions control access = A [OK]

Hint: Permissions control access, not speed or backups [OK]

Common Mistakes:

• Confusing permissions with performance features
• Thinking permissions create database structure
• Assuming permissions handle backups

2. Which Firebase rule syntax correctly allows only authenticated users to read data?

easy

A. "read": "true"

B. "read": "auth != null"

C. "read": "auth == null"

D. "read": "false"

Solution

1. Step 1: Understand auth variable

   In Firebase rules, auth != null means user is logged in.

2. Step 2: Match condition to requirement

   Allowing read only if auth != null means only authenticated users can read.

3. Final Answer:

   "read": "auth != null" -> Option B

4. Quick Check:

   auth != null means logged in = C [OK]

Hint: auth != null means user is logged in [OK]

Common Mistakes:

• Using auth == null which allows unauthenticated users
• Setting read to true allows everyone
• Setting read to false blocks all reads

3. Given this Firebase rule snippet:

{
  "rules": {
    "messages": {
      ".read": "auth != null",
      ".write": "auth.uid == data.child('owner').val()"
    }
  }
}

What happens if a logged-in user tries to write a message where they are not the owner?

medium

A. Write is denied because user is not the owner

B. Write is allowed because user is logged in

C. Write is allowed for all users

D. Write causes a syntax error

Solution

1. Step 1: Analyze write condition

   Write is allowed only if auth.uid equals the owner field in data.

2. Step 2: Check user ownership

   If user is not owner, condition fails, so write is denied.

3. Final Answer:

   Write is denied because user is not the owner -> Option A

4. Quick Check:

   Write allowed only if user owns data = D [OK]

Hint: Write allowed only if auth.uid matches owner [OK]

Common Mistakes:

• Assuming logged-in users can write anywhere
• Confusing read and write rules
• Ignoring the owner check in write condition

4. Identify the error in this Firebase rule snippet:

{
  "rules": {
    "posts": {
      ".read": "auth != null",
      ".write": "auth.uid = data.child('author').val()"
    }
  }
}

medium

A. data.child() cannot be used in rules

B. Missing quotes around auth.uid

C. auth != null is invalid syntax

D. Using single equals (=) instead of double equals (==) in write condition

Solution

1. Step 1: Check write condition syntax

   Single equals (=) is assignment, not comparison in Firebase rules.

2. Step 2: Correct comparison operator

   Use double equals (==) to compare auth.uid and data.child('author').val().

3. Final Answer:

   Using single equals (=) instead of double equals (==) in write condition -> Option D

4. Quick Check:

   Use == for comparison, not = [OK]

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

Common Mistakes:

• Confusing assignment (=) with comparison (==)
• Thinking auth.uid needs quotes
• Believing data.child() is invalid in rules

5. You want to allow users to read all their own profile data but prevent others from reading it. Which Firebase rule correctly enforces this?

{
  "rules": {
    "profiles": {
      "$userId": {
        ".read": "?",
        ".write": "auth.uid == $userId"
      }
    }
  }
}

hard

A. "auth != null"

B. "true"

C. "auth.uid == $userId"

D. "auth.uid != $userId"

Solution

1. Step 1: Understand read condition need

   Users should read only their own profile, so read must check auth.uid equals $userId.

2. Step 2: Match read condition to requirement

   Setting ".read": "auth.uid == $userId" restricts read access to owner only.

3. Final Answer:

   "auth.uid == $userId" -> Option C

4. Quick Check:

   Read allowed only if user matches profile ID = B [OK]

Hint: Read only if auth.uid equals profile ID [OK]

Common Mistakes:

• Using auth != null allows all logged-in users to read
• Setting read to true allows everyone
• Using auth.uid != $userId allows others to read