Realtime Database security rules in Firebase - Step-by-Step Execution

Process Flow - Realtime Database security rules

Client Request

↓

Check Authentication?

No→Deny Access

Yes↓

Evaluate Security Rules

↓

Allow or Deny Based on Rules

↓

Database Read/Write Operation

When a client requests data, Firebase checks if they are authenticated, then evaluates security rules to allow or deny access.

Execution Sample

Firebase

{
  "rules": {
    "messages": {
      "$messageId": {
        ".read": "auth != null",
        ".write": "auth.uid === newData.child(\"userId\").val()"
      }
    }
  }
}

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

Process Table

Step	Request Type	Authentication Present?	Rule Evaluated	Access Result
1	Read /messages/123	Yes	".read": "auth != null"	Allowed
2	Write /messages/123	Yes	".write": "auth.uid === newData.child(\"userId\").val() (uid=abc, userId=abc)"	Allowed
3	Write /messages/123	Yes	".write": "auth.uid === newData.child(\"userId\").val() (uid=abc, userId=xyz)"	Denied
4	Read /messages/123	No	".read": "auth != null"	Denied
5	Write /messages/123	No	".write": "auth.uid === newData.child(\"userId\").val()"	Denied

💡 Access is denied if authentication is missing or rules conditions are not met.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
auth	null	present (uid=abc)	present (uid=abc)	present (uid=abc)	null	null
newData.child("userId").val()	unknown	abc	abc	xyz	abc	abc
access	none	allowed	allowed	denied	denied	denied

Key Moments - 2 Insights

Why is access denied when the user is not authenticated even for reading?

Because the rule '.read: "auth != null"' requires the user to be logged in. See execution_table row 4 where authentication is null and access is denied.

Why does writing fail when the authenticated user ID does not match the message's userId?

The write rule checks if 'auth.uid === newData.child("userId").val()'. If they differ, access is denied as shown in execution_table row 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the access result at step 2 when the user is authenticated and owns the message?

A Pending

B Denied

C Allowed

D Error

💡 Hint

Check execution_table row 2 under 'Access Result'

At which step does the condition 'auth != null' fail?

A Step 1

B Step 4

C Step 3

D Step 5

💡 Hint

Look for where 'Authentication Present?' is 'No' in execution_table

If the write rule changed to allow any authenticated user to write, how would step 3's access result change?

A It would become Allowed

B It would remain Denied

C It would cause an error

D It would be Pending

💡 Hint

Refer to execution_table row 3 and the write rule condition

Concept Snapshot

Realtime Database security rules control who can read or write data.
Rules check if a user is authenticated and if they meet conditions.
Example: allow read if logged in, allow write if user owns data.
If rules fail, access is denied.
Always test rules to secure your database.

Full Transcript

Realtime Database security rules work by checking each client request. First, Firebase checks if the user is logged in. If not, access is denied. If logged in, it evaluates the rules you set. For example, you can allow reading only if the user is authenticated, and writing only if the user owns the data. Each step in the execution table shows how requests are checked and either allowed or denied based on these rules. This ensures your database stays secure by only letting the right users access or change data.

Practice

1. What is the main purpose of Firebase Realtime Database security rules?

easy

A. To control who can read or write data in the database

B. To speed up database queries

C. To backup the database automatically

D. To create database indexes

Solution

1. Step 1: Understand the role of security rules

   Security rules are designed to protect data by controlling access permissions.

2. Step 2: Identify the correct purpose

   They do not affect speed, backups, or indexing but focus on access control.

3. Final Answer:

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

4. Quick Check:

   Access control = To control who can read or write data [OK]

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

Common Mistakes:

• Confusing security rules with database performance features
• Thinking rules create backups automatically
• Assuming rules manage indexing

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

easy

A. "read": "user != null"

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

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

D. "read": "auth === true"

Solution

1. Step 1: Recall the correct auth check syntax

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

2. Step 2: Compare options

   "read": "auth != null" uses the correct syntax. Options A and B use wrong variables or conditions. "read": "auth === true" uses invalid comparison.

3. Final Answer:

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

4. Quick Check:

   Authenticated check = auth != null [OK]

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

Common Mistakes:

• Using 'user' instead of 'auth'
• Checking auth == null instead of auth != null
• Using triple equals (===) which is invalid in rules

3. Given the following rule snippet, what will happen if a user tries to write data to /messages when they are not authenticated?

{
  "rules": {
    "messages": {
      ".write": "auth != null"
    }
  }
}

medium

A. The write will be allowed only if the user is authenticated

B. The write will be allowed for all users

C. The write will be denied for all users

D. The write will cause a syntax error

Solution

1. Step 1: Analyze the write condition

   The rule states .write": "auth != null", meaning only authenticated users can write.

2. Step 2: Consider unauthenticated user case

   If the user is not authenticated, auth == null, so write is denied.

3. Final Answer:

   The write will be allowed only if the user is authenticated -> Option A

4. Quick Check:

   auth != null allows writes only for signed-in users [OK]

Hint: auth != null means only signed-in users can write [OK]

Common Mistakes:

• Thinking unauthenticated users can write
• Confusing read and write rules
• Assuming syntax error without checking code

4. Identify the error in this Firebase Realtime Database rule snippet:

{
  "rules": {
    "users": {
      ".read": "auth != null",
      ".write": "auth.id == auth.uid"
    }
  }
}

medium

A. The write rule should use 'auth.uid != null'

B. The read rule should be 'auth == null' to allow access

C. The rules object is missing a closing brace

D. The write rule uses 'auth.id' which is incorrect

Solution

1. Step 1: Check the write rule syntax

   The write rule uses auth.id, but the correct property is auth.uid.

2. Step 2: Verify other parts

   The read rule is correct to allow authenticated users. The braces are balanced. The write rule should compare auth.uid.

3. Final Answer:

   The write rule uses 'auth.id' which is incorrect -> Option D

4. Quick Check:

   Use auth.uid, not auth.id [OK]

Hint: Use auth.uid for user ID, not auth.id [OK]

Common Mistakes:

• Using wrong property name 'auth.id'
• Changing read rule incorrectly
• Assuming syntax error due to braces

5. You want to allow users to read and write only their own profile data stored under /users/{userId}. Which rule correctly enforces this?

hard

A. {
"rules": {
"users": {
".read": "auth.uid == $userId",
".write": "auth.uid == $userId"
}
}
}

B. {
"rules": {
"users": {
"$userId": {
".read": "auth != null",
".write": "auth != null"
}
}
}
}

C. {
"rules": {
"users": {
"$userId": {
".read": "auth != null && auth.uid == $userId",
".write": "auth != null && auth.uid == $userId"
}
}
}
}

D. {
"rules": {
"users": {
"$userId": {
".read": "true",
".write": "true"
}
}
}
}

Solution

1. Step 1: Understand the requirement

   Users should only access their own data under /users/{userId}.

2. Step 2: Check each option

   { "rules": { "users": { "$userId": { ".read": "auth != null && auth.uid == $userId", ".write": "auth != null && auth.uid == $userId" } } } } correctly checks that the authenticated user's ID matches the path variable $userId for both read and write. { "rules": { "users": { "$userId": { ".read": "auth != null", ".write": "auth != null" } } } } allows any authenticated user to access all profiles. { "rules": { "users": { ".read": "auth.uid == $userId", ".write": "auth.uid == $userId" } } } uses $userId outside its scope. { "rules": { "users": { "$userId": { ".read": "true", ".write": "true" } } } } allows everyone access.

3. Final Answer:

   { "rules": { "users": { "$userId": { ".read": "auth != null && auth.uid == $userId", ".write": "auth != null && auth.uid == $userId" } } } } -> Option C

4. Quick Check:

   auth.uid == $userId restricts access to own data [OK]

Hint: Match auth.uid with $userId in path for user-specific access [OK]

Common Mistakes:

• Allowing all authenticated users access to all profiles
• Using variables outside their scope
• Setting rules to true allowing public access