Realtime Database security rules in Firebase - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the main purpose of Realtime Database security rules in Firebase?

They control who can read or write data in the database, protecting data from unauthorized access.

beginner

How do you specify read and write permissions in Realtime Database security rules?

Using the read and write properties inside rules, set to true or false or expressions that evaluate to boolean.

beginner

What does auth != null mean in a security rule?

It means the user must be signed in (authenticated) to pass the rule and access the data.

intermediate

Why is it important to test your Realtime Database security rules?

To make sure only authorized users can access or change data, preventing data leaks or unwanted changes.

beginner

What happens if no security rules are set in Realtime Database?

By default, the database is locked and no one can read or write data until rules allow it.

In Firebase Realtime Database rules, what does auth != null check?

A User is signed in

B User is an admin

C User has read permission

D User is offline

The expression auth != null means the user must be authenticated (signed in).

Which property controls write access in Realtime Database security rules?

A access

B read

C write

D update

The write property defines who can write or change data.

What is the default access level if no rules are set in Firebase Realtime Database?

A Full public access

B Write-only access

C Read-only access

D No access for anyone

By default, the database denies all reads and writes until rules allow access.

How can you allow only the owner of a data node to write to it?

A Allow write only on weekends

B Check if <code>auth.uid</code> matches the data owner ID

C Use <code>read: true</code> instead

D Set <code>write: true</code> globally

You compare auth.uid with the owner ID stored in data to restrict write access.

Why should you avoid setting read and write to true for all users?

A It exposes your data to anyone, risking security

B It makes the database slower

C It costs more money

D It disables authentication

Allowing all users to read and write can expose sensitive data and cause security breaches.

Explain how Firebase Realtime Database security rules control access to data.

Think about who can read or write data and how rules check user identity.

Describe a simple rule that allows only signed-in users to read and write their own data.

Use auth.uid and data path matching in rules.

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