Firebase Security Vulnerability: FBR-STYLE-001¶
Name: Firebase Security Rules Excessive Complexity Anti-Pattern
Applicable Services: Cloud Firestore, Firebase Realtime Database, Firebase Storage
Description¶
Technical Issue Overview
The Technical Flaw: Security rules with excessive complexity create multiple layers of nested conditional logic, making it difficult to understand the intended access control behavior and increasing the likelihood of introducing security vulnerabilities during maintenance.
Intended Behavior: Security rules should be written with clarity and maintainability in mind, using helper functions, clear variable names, and logical organization to make the intended security behavior obvious to developers.
The Risk: Complex rules are prone to logical errors during updates, make security audits difficult, and can lead to unintended access permissions or rule conflicts that create security vulnerabilities.
Impact¶
Potential Consequences
While not directly exploitable, complex rules create significant operational and security risks:
- Increased Vulnerability Risk: Complex logic is more prone to errors that can introduce security flaws during rule updates or modifications
- Difficult Security Audits: Security reviews become challenging when rules are hard to understand, potentially missing security issues
- Maintenance Errors: Updates to complex rules often introduce unintended side effects or break existing functionality
- Debugging Difficulties: When access control issues occur, complex rules make it difficult to identify and fix the root cause
- Team Productivity Loss: Developers spend excessive time understanding and modifying complex rules instead of building features
- Rule Conflicts: Complex interdependencies can create unexpected rule interactions that bypass intended security controls
Example Attack Scenarios¶
Exploit Scenario: Maintenance-Induced Security Bypass
The Complex Rule:
match /documents/{docId} {
allow read, write: if request.auth != null &&
((request.resource.data.status == 'published' &&
request.resource.data.visibility == 'public' &&
request.resource.data.category in ['news', 'blog', 'announcement']) ||
(request.auth.uid == resource.data.authorId &&
request.resource.data.status != 'archived' &&
request.time < resource.data.expiryDate &&
(resource.data.permissions.contains('edit') ||
resource.data.collaborators.hasAny([request.auth.uid]) &&
request.resource.data.lastModified > (request.time - duration.value(24, 'h'))))) &&
get(/databases/$(database)/documents/users/$(request.auth.uid)).data.accountStatus == 'active';
}
Developer's Goal: To add a new document category 'tutorial' to the allowed list.
The Maintenance Error: During a routine update, a developer makes a logical error:
// Developer incorrectly modifies the complex rule
match /documents/{docId} {
allow read, write: if request.auth != null &&
((request.resource.data.status == 'published' &&
request.resource.data.visibility == 'public' &&
request.resource.data.category in ['news', 'blog', 'announcement', 'tutorial']) ||
// MISTAKE: Removed critical authorization check
(request.resource.data.status != 'archived' &&
request.time < resource.data.expiryDate &&
(resource.data.permissions.contains('edit') ||
resource.data.collaborators.hasAny([request.auth.uid]) &&
request.resource.data.lastModified > (request.time - duration.value(24, 'h'))))) &&
get(/databases/$(database)/documents/users/$(request.auth.uid)).data.accountStatus == 'active';
}
Outcome: The developer accidentally removes the author ownership check (request.auth.uid == resource.data.authorId), allowing any authenticated user to modify any non-archived document, creating a severe security vulnerability.
Exploit Scenario: Logic Error in Complex Permission Rules
The Complex Rule:
match /financial_transactions/{transactionId} {
allow read: if request.auth != null &&
(request.auth.uid == resource.data.fromUserId ||
request.auth.uid == resource.data.toUserId ||
(request.auth.token.role == 'admin' &&
resource.data.amount < 10000) ||
(request.auth.token.role == 'auditor' &&
resource.data.createdAt > (request.time - duration.value(30, 'd')) &&
resource.data.status in ['pending', 'processing']) ||
(get(/databases/$(database)/documents/users/$(request.auth.uid)).data.department == 'finance' &&
resource.data.requiresApproval == false &&
resource.data.amount < 1000));
allow write: if request.auth != null &&
request.auth.uid == resource.data.fromUserId &&
resource.data.status == 'draft' &&
request.resource.data.amount <= get(/databases/$(database)/documents/users/$(request.auth.uid)).data.transferLimit;
}
Developer's Goal: To allow finance department members to view all transactions under $5000.
The Logic Error: Due to complex operator precedence, the rule has an unintended logical flaw:
// Test case that exposes the vulnerability
const maliciousUser = {
uid: 'attacker-123',
token: { role: 'user' }, // Not admin or auditor
department: 'marketing' // Not finance
};
const sensitiveTransaction = {
fromUserId: 'victim-456',
toUserId: 'bank-account-789',
amount: 50000, // High value transaction
requiresApproval: false,
status: 'completed',
createdAt: new Date('2023-01-01') // Old transaction
};
// Due to complex logic, this user can access the transaction
// because the rule evaluation doesn't properly enforce all conditions
Outcome: The complex rule logic creates an unintended access path that allows unauthorized users to view sensitive financial transactions.
Mitigation¶
The vulnerability is resolved by refactoring complex rules into smaller, well-organized functions with clear naming and logical structure.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// COMPLEX: Difficult to read and maintain
match /posts/{postId} {
allow update: if request.auth != null &&
(request.resource.data.status == 'published' &&
request.resource.data.visibility == 'public') ||
(request.auth.uid == resource.data.authorId &&
request.resource.data.status != 'archived') &&
request.resource.data.lastUpdated > (request.time - duration.value(5, 'm'));
}
// COMPLEX: Financial transaction rule with multiple conditions
match /transactions/{transactionId} {
allow read: if request.auth != null &&
(request.auth.uid == resource.data.fromUserId ||
request.auth.uid == resource.data.toUserId ||
(request.auth.token.role == 'admin' && resource.data.amount < 10000) ||
(request.auth.token.role == 'auditor' &&
resource.data.createdAt > (request.time - duration.value(30, 'd')) &&
resource.data.status in ['pending', 'processing']) ||
(get(/databases/$(database)/documents/users/$(request.auth.uid)).data.department == 'finance' &&
resource.data.requiresApproval == false && resource.data.amount < 1000));
}
}
}
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Helper functions for post access control
function isPublicPublished() {
return request.resource.data.status == 'published' &&
request.resource.data.visibility == 'public';
}
function isAuthorAndNotArchived() {
return request.auth.uid == resource.data.authorId &&
request.resource.data.status != 'archived';
}
function wasUpdatedRecently() {
return request.resource.data.lastUpdated > (request.time - duration.value(5, 'm'));
}
function isAuthenticated() {
return request.auth != null;
}
// SIMPLIFIED: Clear, readable post access rules
match /posts/{postId} {
allow update: if isAuthenticated() &&
(isPublicPublished() || isAuthorAndNotArchived()) &&
wasUpdatedRecently();
}
// Helper functions for transaction access control
function isTransactionParticipant() {
return request.auth.uid == resource.data.fromUserId ||
request.auth.uid == resource.data.toUserId;
}
function isAdminWithLimitedAccess() {
return request.auth.token.role == 'admin' &&
resource.data.amount < 10000;
}
function isAuditorWithRecentAccess() {
return request.auth.token.role == 'auditor' &&
resource.data.createdAt > (request.time - duration.value(30, 'd')) &&
resource.data.status in ['pending', 'processing'];
}
function isFinanceWithLimitedAccess() {
return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.department == 'finance' &&
resource.data.requiresApproval == false &&
resource.data.amount < 1000;
}
// SIMPLIFIED: Clear transaction access rules
match /transactions/{transactionId} {
allow read: if isAuthenticated() &&
(isTransactionParticipant() ||
isAdminWithLimitedAccess() ||
isAuditorWithRecentAccess() ||
isFinanceWithLimitedAccess());
}
}
}
Security Rules Organization Best Practices
Function Decomposition: Break complex conditions into smaller, single-purpose functions with descriptive names that clearly indicate their purpose.
Logical Grouping: Organize related functions together and use consistent naming patterns (e.g., isUserAllowed, hasValidPermission, canAccessResource).
Clear Documentation: Add comments to explain business logic, especially for complex authorization scenarios:
// Allow finance department to view small transactions that don't require approval
function isFinanceWithLimitedAccess() {
return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.department == 'finance' &&
resource.data.requiresApproval == false &&
resource.data.amount < 1000;
}
Key Organizational Principles: - Single Responsibility: Each function should check one specific condition - Meaningful Names: Function names should clearly describe what they validate - Consistent Patterns: Use similar naming conventions across your rules - Testability: Simple functions are easier to test and verify - Reusability: Well-designed functions can be reused across multiple rules
Testing Complex Rules: