Authentication-based rules in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Firebase rule behavior with authenticated users

Consider this Firebase Realtime Database rule snippet:

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

What happens when a logged-in user tries to write a message where the 'owner' field is not equal to their user ID?

A The write is denied because the user is not the owner of the existing message.

B The write is allowed because the user is authenticated.

C The write is denied because the user is not authenticated.

D The write is allowed only if the message does not exist yet.

💡 Hint

Check the condition for '.write' and what 'data.child('owner').val()' means.

The rule requires the user to be authenticated and their user ID to match the 'owner' field of the existing message. If the 'owner' does not match, the write is denied.

🧠 Conceptual

intermediate

Understanding Firebase auth variable in rules

In Firebase Realtime Database security rules, what does the auth variable represent?

A The list of all users currently connected to the database.

B The database reference path of the current read or write operation.

C The server timestamp when the request is processed.

D The authentication token of the current user making the request, or null if unauthenticated.

💡 Hint

Think about how Firebase identifies who is making a request.

The auth variable contains the user's authentication info if logged in, or null if not.

❓ security

advanced

Preventing unauthorized data deletion in Firebase

Given this Firebase rule:

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

Which of the following actions is not allowed by this rule?

A A user creating their own profile data.

B A user deleting their own profile data.

C A user updating another user's profile data.

D A user updating their own profile data.

💡 Hint

Check the condition comparing auth.uid and $uid.

The rule only allows writes when the authenticated user's ID matches the user ID in the path. Writing to another user's data is denied.

❓ Configuration

advanced

Configuring Firebase rules for public read and authenticated write

You want to allow anyone to read data under /posts but only authenticated users to write. Which rule configuration achieves this?

A

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

B

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

C

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

D

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

💡 Hint

Remember true means anyone can read.

Setting .read to true allows public read access. Setting .write to auth != null restricts writes to authenticated users.

❓ Architecture

expert

Designing Firebase rules for multi-role access control

You have a Firebase Realtime Database with a /projects node. Each project has an ownerId and a list of collaborators (user IDs). You want to allow:

• Owners to read and write their projects.
• Collaborators to read but not write.
• Others no access.

Which rule snippet correctly implements this?

A

{
  "rules": {
    "projects": {
      "$projectId": {
        ".read": "auth != null && (auth.uid == data.child('ownerId').val() || data.child('collaborators').hasChild(auth.uid))",
        ".write": "auth != null && auth.uid == data.child('ownerId').val()"
      }
    }
  }
}

B

{
  "rules": {
    "projects": {
      "$projectId": {
        ".read": "auth != null && auth.uid == data.child('ownerId').val()",
        ".write": "auth != null && (auth.uid == data.child('ownerId').val() || data.child('collaborators').hasChild(auth.uid))"
      }
    }
  }
}

C

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

D

{
  "rules": {
    "projects": {
      "$projectId": {
        ".read": "auth != null",
        ".write": "auth != null && auth.uid == data.child('ownerId').val()"
      }
    }
  }
}

💡 Hint

Think about who can read and who can write, and how to check collaborators.

Option A allows read access to owners and collaborators, write access only to owners. Others have no access. Other options either allow too much or too little access.