Realtime Database security rules in Firebase - Commands & Configuration

Introduction

Realtime Database security rules control who can read or write data in your Firebase database. They protect your data from unauthorized access and keep it safe.

When you want only logged-in users to read and write their own data.

When you need to prevent anyone from deleting important data accidentally.

When you want to allow public read access but restrict write access to admins.

When you want to validate data format before saving it to the database.

When you want to limit how much data a user can write to avoid abuse.

Config File - database.rules.json

database.rules.json

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

This file sets the security rules for your Firebase Realtime Database.

• .read and .write at the root level allow only authenticated users to read and write anywhere.
• The users node has a variable $uid representing each user ID.
• Inside users/$uid, only the user with matching auth.uid can read or write their own data.

Commands

This command uploads and activates your Realtime Database security rules to Firebase. It makes your rules live to protect your data.

Terminal

firebase deploy --only database

Expected Output

=== Deploying to 'your-project-id'...



i  deploying database

i  database: checking rules syntax...

✔  database: rules syntax for database Realtime Database is valid



✔  Deploy complete!



Project Console: https://console.firebase.google.com/project/your-project-id/overview

→

--only - Deploy only the database rules without affecting other Firebase services

This command fetches data at the path /users/user123 to verify if the authenticated user can read their own data according to the rules.

Terminal

firebase database:get /users/user123

Expected Output

{

  "name": "Alice",

  "email": "[e-mail]"

}

This command updates the data for user123 to test if the write rule allows the authenticated user to change their own data.

Terminal

firebase database:set /users/user123 '{"name":"Alice Updated"}'

Expected Output

null

Key Concept

If you remember nothing else from this pattern, remember: security rules control who can read or write each part of your database based on user identity.

Common Mistakes

Setting .read and .write to true for everyone

This makes your database open to anyone, risking data leaks and unauthorized changes.

Always require authentication by using auth != null and restrict access to specific users or roles.

Not using variables like $uid to match user IDs

Without variables, you cannot restrict users to only their own data, allowing them to access others' data.

Use path variables like $uid and compare them to auth.uid to enforce user-specific access.

Deploying rules without testing them

Incorrect rules can lock out all users or leave data unprotected.

Test rules locally or with Firebase Emulator before deploying, and verify with read/write commands.

Summary

Write security rules in a JSON file to control database access.

Deploy rules using the firebase CLI to make them active.

Test read and write permissions with firebase database commands.

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