Bird
Raised Fist0
Firebasecloud~5 mins

Common rule patterns in Firebase - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Common rule patterns
O(n)
Understanding Time Complexity

When using Firebase security rules, it's important to know how the number of checks grows as your data or requests grow.

We want to understand how the time to evaluate rules changes when more data or requests are involved.

Scenario Under Consideration

Analyze the time complexity of these Firebase rules checking multiple documents.


service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if request.auth != null &&
        exists(/databases/$(database)/documents/users/$(request.auth.uid)) &&
        get(/databases/$(database)/documents/posts/$(postId)).data.published == true;
    }
  }
}
    

These rules check if the user exists and if the post is published before allowing read access.

Identify Repeating Operations

Look at what happens each time a read request is made:

  • Primary operation: Two document reads: one to check the user document, one to check the post document.
  • How many times: Once per read request for each post.
How Execution Grows With Input

As the number of read requests grows, the number of document reads grows the same way.

Input Size (n)Approx. Api Calls/Operations
1020 document reads (2 per request)
100200 document reads
10002000 document reads

Pattern observation: The number of operations grows directly with the number of requests.

Final Time Complexity

Time Complexity: O(n)

This means the time to check rules grows linearly with the number of read requests.

Common Mistake

[X] Wrong: "Checking multiple documents in rules happens all at once and does not add time."

[OK] Correct: Each document read in rules is a separate operation, so more checks mean more time.

Interview Connect

Understanding how rule checks scale helps you design efficient security rules that keep your app fast and safe.

Self-Check

What if we added a loop in rules to check multiple related documents? How would the time complexity change?

Practice

(1/5)
1. What is the main purpose of Firebase security rules in a database?
easy
A. To control who can read or write data
B. To speed up database queries
C. To store user passwords securely
D. To backup data automatically

Solution

  1. Step 1: Understand Firebase security rules role

    Firebase security rules define who can access or change data in your database.
  2. Step 2: Identify the main function

    The main function is to control read and write access to protect data.
  3. Final Answer:

    To control who can read or write data -> Option A
  4. Quick Check:

    Security rules = access control [OK]
Hint: Rules control data access permissions quickly [OK]
Common Mistakes:
  • Confusing rules with data backup
  • Thinking rules speed up queries
  • Assuming rules store passwords
2. Which of the following is the correct syntax to allow only authenticated users to read data in Firebase rules?
easy
A. allow read: if request.auth != null;
B. allow read: if user.loggedIn == true;
C. allow read: if auth.user == true;
D. allow read: if request.user != null;

Solution

  1. Step 1: Identify correct Firebase auth syntax

    Firebase uses request.auth to check if a user is authenticated.
  2. Step 2: Match syntax to allow read only if authenticated

    The correct condition is request.auth != null meaning user is logged in.
  3. Final Answer:

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

    request.auth != null means user logged in [OK]
Hint: Use request.auth to check user authentication [OK]
Common Mistakes:
  • Using incorrect variable names like user.loggedIn
  • Checking auth.user instead of request.auth
  • Confusing request.user with request.auth
3. Given this Firebase rule snippet:
allow write: if request.auth.uid == resource.data.ownerId;

What does this rule enforce?
medium
A. No one can write to the data
B. Only the owner of the data can write to it
C. Anyone can write if authenticated
D. Only admins can write to the data

Solution

  1. Step 1: Understand the condition in the rule

    The rule checks if the user's ID matches the ownerId stored in the data.
  2. Step 2: Interpret the effect of the condition

    This means only the user who owns the data (ownerId) can write to it.
  3. Final Answer:

    Only the owner of the data can write to it -> Option B
  4. Quick Check:

    request.auth.uid == resource.data.ownerId means owner only [OK]
Hint: Match request.auth.uid with data ownerId to allow write [OK]
Common Mistakes:
  • Assuming all authenticated users can write
  • Thinking admins are required
  • Believing no one can write
4. Identify the error in this Firebase rule snippet:
allow read: if request.auth.uid = resource.data.ownerId;
medium
A. request.auth.uid is not a valid property
B. Missing semicolon at the end of the line
C. Using single equals (=) instead of double equals (==) for comparison
D. resource.data.ownerId cannot be used in rules

Solution

  1. Step 1: Check the comparison operator used

    The rule uses a single equals sign (=) which is assignment, not comparison.
  2. Step 2: Correct operator for comparison in Firebase rules

    Firebase rules require double equals (==) to compare values.
  3. Final Answer:

    Using single equals (=) instead of double equals (==) for comparison -> Option C
  4. Quick Check:

    Use == for comparison, not = [OK]
Hint: Use == to compare values in rules, not = [OK]
Common Mistakes:
  • Confusing assignment (=) with comparison (==)
  • Thinking semicolon is mandatory
  • Believing request.auth.uid is invalid
5. You want to allow users to update their own profile but prevent them from changing their user ID. Which Firebase rule pattern correctly enforces this?
hard
A. allow update: if request.auth.uid == request.resource.data.userId;
B. allow update: if request.resource.data.userId == null;
C. allow update: if request.auth.uid != resource.data.userId;
D. allow update: if request.auth.uid == resource.data.userId && request.resource.data.userId == resource.data.userId;

Solution

  1. Step 1: Ensure user can update only their own profile

    The rule must check that the authenticated user matches the existing userId in data.
  2. Step 2: Prevent changing the userId field

    Check that the new data's userId matches the old data's userId to prevent changes.
  3. Final Answer:

    allow update: if request.auth.uid == resource.data.userId && request.resource.data.userId == resource.data.userId; -> Option D
  4. Quick Check:

    Match auth.uid and keep userId unchanged [OK]
Hint: Check auth.uid matches and userId stays same [OK]
Common Mistakes:
  • Allowing userId to be changed
  • Not verifying user owns the profile
  • Using != instead of == for ownership check
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard