Common rule patterns in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Firebase Realtime Database: What does this rule allow?

Given the following Firebase Realtime Database security rule, what does it allow users to do?

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

A Any user can read and write any message regardless of authentication.

B Any authenticated user can read all messages, but only the owner can modify their own messages.

C Only the owner can read and write their messages; others cannot read any messages.

D Anyone can read messages, but only authenticated users can write.

💡 Hint

Look at the conditions for .read and .write separately.

The .read rule requires the user to be authenticated (auth != null), so any signed-in user can read messages. The .write rule requires the user to be authenticated and their uid to match the message's owner field, so only owners can write.

❓ Architecture

intermediate

Firebase Firestore: How to structure rules for user profiles?

You want to allow users to read any profile but only edit their own profile in Firestore. Which rule structure achieves this?

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      // Fill in read and write rules
    }
  }
}

A allow read: if true; allow write: if request.auth.uid == userId;

B allow read, write: if request.auth.uid == userId;

C allow read: if request.auth.uid == userId; allow write: if true;

D allow read, write: if true;

💡 Hint

Think about who should read and who should write.

Allowing read if true means anyone can read profiles. Allowing write only if the authenticated user's uid matches the userId means only owners can edit their profiles.

❓ security

advanced

Firebase Realtime Database: What error occurs with this rule?

Consider this Firebase Realtime Database rule snippet:

{
  "rules": {
    "posts": {
      "$postId": {
        ".write": "auth.uid == newData.child('author').val()"
      }
    }
  }
}

What error will this cause when deploying?

A SyntaxError because 'auth.uid' should be 'auth.uid != null'

B Runtime error because 'newData' is undefined in write rules

C No error; rule is valid and deploys successfully

D Validation error because 'newData' is not allowed; should use 'newData.exists()' first

💡 Hint

Check if 'newData' usage requires existence checks.

'newData' can be null if the write is a delete. The rule must check if 'newData' exists before accessing child values to avoid errors.

✅ Best Practice

advanced

Firestore Rules: Preventing unauthorized document deletion

Which Firestore rule best prevents users from deleting documents they do not own, while allowing them to update other fields?

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /items/{itemId} {
      allow update: if request.auth.uid == resource.data.owner;
      allow delete: ???
    }
  }
}

A allow delete: if true;

B allow delete: if request.auth.uid != null;

C allow delete: if request.auth.uid == resource.data.owner;

D allow delete: if request.auth.uid == request.resource.data.owner;

💡 Hint

Who should be allowed to delete documents?

Only the owner should delete their document. Checking resource.data.owner ensures the user owns the existing document before deletion.

🧠 Conceptual

expert

Firebase Security Rules: What is the effect of this rule order?

Consider these Firebase Realtime Database rules:

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

What is the effective read permission for the path /users/123 if the user is authenticated but their uid is not '123'?

A The user can read /users/123 because the top-level .read allows any authenticated user.

B The user cannot read /users/123 because the more specific rule denies access.

C The user can read /users/123 only if they are the owner (uid == 123).

D The user cannot read /users/123 because .read rules do not cascade.

💡 Hint

Remember how Firebase merges rules at different levels.

In Firebase Realtime Database, rules cascade and the most permissive rule applies. The top-level .read allows any authenticated user to read all data, so the user can read /users/123 even if not owner.