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.