Storage security rules in Firebase - Time & Space Complexity
We want to understand how the time to check storage security rules changes as more files or requests happen.
How does the system handle more requests and how long does each check take?
Analyze the time complexity of the following security rule checks.
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null && request.auth.uid == resource.metadata.ownerId;
}
}
}
This rule allows read and write only if the user is logged in and owns the file.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Checking the security rule for each file access request.
- How many times: Once per file read or write request.
Each request triggers one rule check, regardless of total files stored.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 rule checks |
| 100 | 100 rule checks |
| 1000 | 1000 rule checks |
Pattern observation: The time grows linearly with the number of requests, not with total files stored.
Time Complexity: O(n)
This means the time to check rules grows directly with the number of file access requests.
[X] Wrong: "The rule check time depends on how many files are stored in total."
[OK] Correct: Each check only looks at the single file requested, so total stored files do not affect check time.
Understanding how security rules scale helps you design systems that stay fast and safe as they grow.
"What if the rule checked multiple files at once? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of security rules
Security rules define who can access files and what actions they can perform.Step 2: Identify the main function
The main function is to control read and write permissions to protect data.Final Answer:
To control who can read or write files in storage -> Option AQuick Check:
Security rules = control access [OK]
- Thinking rules speed up uploads
- Believing rules increase storage size
- Confusing rules with backup features
Solution
Step 1: Check Firebase Storage rules syntax
The correct way to check authentication is usingrequest.auth != null.Step 2: Compare options
Only allow read: if request.auth != null; uses the correct Firebase syntax for authentication check.Final Answer:
allow read: if request.auth != null; -> Option AQuick Check:
Authentication check = request.auth != null [OK]
- Using incorrect variable names like user.authenticated
- Missing the 'request.' prefix
- Using wrong boolean checks
service firebase.storage {
match /b/{bucket}/o {
match /files/{fileId} {
allow read: if request.auth != null;
allow write: if false;
}
}
}Solution
Step 1: Analyze the read rule condition
The rule allows read only ifrequest.auth != null, meaning user must be authenticated.Step 2: Consider unauthenticated user
An unauthenticated user hasrequest.auth == null, so the condition fails and read is denied.Final Answer:
The read request is denied because the user is not authenticated -> Option DQuick Check:
Unauthenticated read = denied [OK]
- Ignoring the read condition and assuming access
- Confusing read and write permissions
- Thinking false write affects read
service firebase.storage {
match /b/{bucket}/o {
match /users/{userId}/{allPaths=**} {
allow write: if request.auth.uid == userId;
}
}
}Solution
Step 1: Check path variables
The path correctly defines {userId} and {allPaths=**} wildcards.Step 2: Review condition and permissions
The condition correctly comparesrequest.auth.uidwithuserIdfor write permission.Step 3: Identify missing read permission
The rule only allows write, no read permission is granted, which may block legitimate reads.Final Answer:
The rule does not allow read access -> Option CQuick Check:
Missing read permission = problem [OK]
- Assuming write permission covers read
- Confusing request.auth.uid with userId variable
- Misusing wildcard syntax
service firebase.storage {
match /b/{bucket}/o {
match /users/{userId}/{fileName} {
allow write: if request.auth.uid == userId && request.resource.size < 2 * 1024 * 1024;
allow read: if request.auth.uid == userId;
}
}
}Solution
Step 1: Verify user ownership condition
The rule checksrequest.auth.uid == userIdto ensure users write only to their folder.Step 2: Verify file size condition
The rule usesrequest.resource.size < 2 * 1024 * 1024to limit uploads to less than 2MB.Step 3: Confirm read permission
Read is allowed only for the authenticated user matchinguserId.Final Answer:
This rule correctly enforces user ownership and file size limit -> Option BQuick Check:
User ID and size check = correct [OK]
- Using resource.size instead of request.resource.size
- Not checking user ID for write
- Checking size on existing file instead of upload
Ready to prove it?
Pass the test and this pattern moves unknown
