Realtime Database security rules in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Read Access in Realtime Database Rules

Given the following Firebase Realtime Database security rule snippet, what will happen when an unauthenticated user tries to read data at /messages?

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

A The read request will be allowed only if the user has a verified email.

B The read request will be allowed because read rules are open by default.

C The read request will be denied because the user is not authenticated.

D The read request will be denied because write permission is required for reading.

💡 Hint

Check the condition for .read and what auth != null means.

The rule .read": "auth != null" means only authenticated users can read data. Unauthenticated users have auth == null, so their read requests are denied.

❓ Configuration

intermediate

Rule to Allow Writes Only by Owner

Which of the following Firebase Realtime Database security rules correctly allows write access only if the authenticated user's UID matches the ownerId field in the data being written at /posts/{postId}?

A

{
  "rules": {
    "posts": {
      "$postId": {
        ".write": "auth != null && auth.uid == newData.child('ownerId').val()"
      }
    }
  }
}

B

{
  "rules": {
    "posts": {
      "$postId": {
        ".write": "auth != null && auth.uid == data.child('ownerId').val()"
      }
    }
  }
}

C

{
  "rules": {
    "posts": {
      "$postId": {
        ".write": "auth != null && auth.uid == $postId"
      }
    }
  }
}

D

{
  "rules": {
    "posts": {
      "$postId": {
        ".write": "auth != null && data.exists() && auth.uid == data.child('ownerId').val()"
      }
    }
  }
}

💡 Hint

Remember that newData refers to the incoming data being written, while data refers to existing data.

To allow write only if the new data's ownerId matches the authenticated user's UID, the rule must check newData.child('ownerId').val(). Option A correctly does this. Option A checks existing data, which may block new posts. Option A incorrectly compares UID to the post ID. Option A requires existing data, blocking new posts.

❓ Architecture

advanced

Designing Rules for Public Read and Owner-Only Write

You want to design Firebase Realtime Database rules for /profiles/{userId} so that:

• Anyone can read any profile.
• Only the profile owner can write to their profile.

Which rule set below correctly implements this?

A

{
  "rules": {
    "profiles": {
      "$userId": {
        ".read": "true",
        ".write": "auth != null && auth.uid == data.child('userId').val()"
      }
    }
  }
}

B

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

C

{
  "rules": {
    "profiles": {
      "$userId": {
        ".read": "true",
        ".write": "auth != null && auth.uid == newData.child('userId').val()"
      }
    }
  }
}

D

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

💡 Hint

Check which variable holds the user ID in the path and how to allow public read.

Option D allows anyone to read because .read is true. It restricts write to authenticated users whose UID matches the path variable $userId. Option D restricts read to authenticated users only, which is not public. Options C and D check fields inside data, which may be missing or manipulated, less secure than path-based check.

❓ security

advanced

Identifying a Security Risk in Realtime Database Rules

Consider the following Firebase Realtime Database security rules:

{
  "rules": {
    "orders": {
      ".read": "auth != null",
      ".write": "true"
    }
  }
}

What is the main security risk with these rules?

A Only authenticated users can read orders, but anyone can write, risking data tampering.

B Only authenticated users can write, but read is open to all.

C No one can read or write orders because the rules are contradictory.

D Anyone can write to the orders node, even unauthenticated users.

💡 Hint

Look at the .write rule and who it allows.

The .write rule is set to true, meaning anyone, including unauthenticated users, can write data. The .read rule restricts reads to authenticated users only. This mismatch allows unauthenticated users to tamper with data, which is a security risk.

✅ Best Practice

expert

Optimizing Realtime Database Rules for Performance and Security

You have a large Firebase Realtime Database with many nested nodes. You want to write security rules that:

• Minimize rule evaluation time.
• Prevent unauthorized access efficiently.

Which approach below follows best practices for writing efficient and secure rules?

A Use <code>true</code> for most rules to reduce evaluation time and rely on client-side checks.

B Write specific rules at each node level, avoiding deep nesting and using path variables for ownership checks.

C Write broad rules at the root level with complex conditions to cover all nodes.

D Duplicate rules in multiple places to ensure coverage, even if it increases rule size.

💡 Hint

Think about how Firebase evaluates rules and the impact of rule complexity.

Option B is best practice: writing specific rules at each node reduces unnecessary evaluations and improves security by limiting access precisely. Broad root-level rules with complex conditions (Option B) slow down evaluation. Using true widely (Option B) is insecure. Duplicating rules (Option B) increases maintenance and can cause conflicts.

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