Why security rules protect data in Firebase - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to allow read access only if the user is authenticated.

Firebase

allow read: if request.auth [1] null;

Drag options to blanks, or click blank then click option'

A>

B==

C!=

D<

Attempts:

3 left

💡 Hint

Common Mistakes

Using '==' instead of '!=' causes unauthenticated users to have access.

Using '<' or '>' operators here does not make sense.

The rule checks that the user is signed in by verifying request.auth != null. This means only authenticated users can read data.

2fill in blank

medium

Complete the code to allow write access only if the user's ID matches the data owner ID.

Firebase

allow write: if request.auth.uid [1] resource.data.ownerId;

Drag options to blanks, or click blank then click option'

A==

B!=

C<=

D>

Attempts:

3 left

💡 Hint

Common Mistakes

Using '!=' allows others to write data they don't own.

Using comparison operators like '<=' or '>' is incorrect here.

This rule allows writes only if the signed-in user's ID matches the owner ID stored in the data, ensuring only owners can modify their data.

3fill in blank

hard

Fix the error in the rule that denies all access.

Firebase

allow read, write: if [1];

Drag options to blanks, or click blank then click option'

Atrue

Bfalse

Cnull

Drequest.auth != null

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'true' allows all access.

Using 'null' causes errors.

Using 'request.auth != null' allows access only to authenticated users.

Using false denies all access, which is the intended behavior here.

4fill in blank

hard

Fill both blanks to allow read access only if the user is authenticated and the document is not marked private.

Firebase

allow read: if request.auth [1] null && resource.data.private [2] false;

Drag options to blanks, or click blank then click option'

A!=

B==

Attempts:

3 left

💡 Hint

Common Mistakes

Using '==' instead of '!=' for the auth check.

Using '!=' instead of '==' for the private field check.

The rule checks that the user is signed in (request.auth != null) and that the document's private field is false, meaning it is public.

5fill in blank

hard

Fill all three blanks to allow write access only if the user is authenticated, owns the data, and the new data has a valid status.

Firebase

allow write: if request.auth [1] null && request.auth.uid [2] resource.data.ownerId && request.resource.data.status [3] ['active', 'pending'];

Drag options to blanks, or click blank then click option'

A!=

B==

Cin

Dnot-in

Attempts:

3 left

💡 Hint

Common Mistakes

Using '==' instead of '!=' for auth check.

Using '!=' instead of '==' for owner check.

Using 'not-in' instead of 'in' for status check.

This rule ensures the user is signed in (!= null), owns the data (== ownerId), and the new status is one of the allowed values (in ['active', 'pending']).

Practice

1. Why are Firebase security rules important for your app's data?

easy

A. They change the app's user interface based on user roles.

B. They speed up the app's performance by caching data.

C. They automatically back up your data to the cloud.

D. They control who can read or write data to keep it safe.

Solution

1. Step 1: Understand the role of security rules

   Security rules are designed to control access to data, deciding who can read or write it.

2. Step 2: Identify the main purpose of these rules

   The main goal is to keep data safe and private by restricting unauthorized access.

3. Final Answer:

   They control who can read or write data to keep it safe. -> Option D

4. Quick Check:

   Security rules protect data = They control who can read or write data to keep it safe. [OK]

Hint: Security rules control access to data, not app speed or UI [OK]

Common Mistakes:

• Confusing security rules with performance features
• Thinking rules change app design or backup data
• Assuming rules automatically fix bugs

2. Which of the following is the correct way to write a Firebase security rule that allows only authenticated users to read data?

easy

A. allow read: if request.auth != null;

B. allow read: if user.authenticated == true;

C. allow read: if auth.user == true;

D. allow read: if request.user != null;

Solution

1. Step 1: Recall Firebase rule syntax for authentication

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

2. Step 2: Compare options to correct syntax

   Only allow read: if request.auth != null; uses the correct Firebase syntax for authenticated access.

3. Final Answer:

   allow read: if request.auth != null; -> Option A

4. Quick Check:

   Correct Firebase auth check = allow read: if request.auth != null; [OK]

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

Common Mistakes:

• Using incorrect variable names like user.authenticated
• Confusing request.user with request.auth
• Missing the 'if' keyword in rules

3. Given this Firebase rule snippet:

allow write: if request.auth.uid == resource.data.ownerId;

What happens if a user tries to write data where their UID does not match ownerId?

medium

A. The write is allowed because the rule only checks if user is authenticated.

B. The write is allowed only if the user is an admin.

C. The write is denied because the user's UID does not match the ownerId.

D. The write is denied only if the data is empty.

Solution

1. Step 1: Understand the rule condition

   The rule allows writes only if the user's UID matches the ownerId in the data.

2. Step 2: Analyze the user's UID mismatch

   If the user's UID does not match ownerId, the condition fails, so the write is denied.

3. Final Answer:

   The write is denied because the user's UID does not match the ownerId. -> Option C

4. Quick Check:

   UID mismatch denies write = The write is denied because the user's UID does not match the ownerId. [OK]

Hint: UID must match ownerId to allow write [OK]

Common Mistakes:

• Assuming any authenticated user can write
• Thinking admin rights are checked here
• Ignoring the exact match condition

4. You wrote this Firebase rule:

allow read, write: if request.auth != null && request.auth.uid == resource.data.ownerId;

But users report they cannot write their own data. What is the likely problem?

medium

A. The rule is missing a semicolon at the end.

B. The rule should use request.resource.data.ownerId instead of resource.data.ownerId.

C. The rule should allow all users to write without conditions.

D. The rule should check request.auth.email instead of UID.

Solution

1. Step 1: Understand the difference between resource and request.resource

   resource.data refers to existing data, while request.resource.data refers to new data being written.

2. Step 2: Identify the correct field to check ownerId

   To verify the ownerId in the data being written, use request.resource.data.ownerId.

3. Final Answer:

   The rule should use request.resource.data.ownerId instead of resource.data.ownerId. -> Option B

4. Quick Check:

   Check new data with request.resource = The rule should use request.resource.data.ownerId instead of resource.data.ownerId. [OK]

Hint: Use request.resource for new data checks, not resource [OK]

Common Mistakes:

• Confusing resource with request.resource
• Ignoring the need to check new data fields
• Removing conditions to fix access issues

5. You want to protect a collection so that users can only read their own documents and write only if they are the owner. Which rule correctly enforces this?

hard

A. allow read: if request.auth.uid == resource.data.ownerId; allow write: if request.auth.uid == request.resource.data.ownerId;

B. allow read: if resource.data.ownerId == request.auth.uid; allow write: if request.auth.uid == resource.data.ownerId;

C. allow read, write: if request.auth != null;

D. allow read, write: if request.auth.uid == resource.data.ownerId && request.auth.uid == request.resource.data.ownerId;

Solution

1. Step 1: Understand read and write conditions

   Reads check existing data's ownerId with resource.data.ownerId. Writes check new data's ownerId with request.resource.data.ownerId.

2. Step 2: Match conditions to options

   allow read: if request.auth.uid == resource.data.ownerId; allow write: if request.auth.uid == request.resource.data.ownerId; correctly separates read and write checks using the right references for existing and new data.

3. Final Answer:

   allow read: if request.auth.uid == resource.data.ownerId; allow write: if request.auth.uid == request.resource.data.ownerId; -> Option A

4. Quick Check:

   Read uses resource, write uses request.resource = allow read: if request.auth.uid == resource.data.ownerId; allow write: if request.auth.uid == request.resource.data.ownerId; [OK]

Hint: Read checks resource, write checks request.resource for ownerId [OK]

Common Mistakes:

• Using same data reference for read and write
• Allowing all authenticated users to write
• Not checking ownership on writes