Regex Dos in Firestore

Regular expression denial of service (ReDoS) in Firestore occurs when user-controlled input is used in regex operations that have exponential worst-case complexity. Firestore's query capabilities and indexing system can be exploited when regex patterns are dynamically constructed from untrusted data.

The most common attack pattern involves using client-provided regex patterns in queries like:

db.collection('users')
  .where('email', 'regex', userInput)

Firestore supports regex queries through the regex operator, but this becomes dangerous when the pattern itself is user-controlled. An attacker can craft regex patterns that trigger catastrophic backtracking, causing the query engine to consume excessive CPU resources.

Consider this vulnerable pattern:

const searchPattern = req.query.pattern; // User-controlled
db.collection('products')
  .where('description', 'regex', searchPattern)
  .get()

An attacker could submit patterns like (a+)+b which has exponential matching time for certain inputs. With Firestore's distributed architecture, a single malicious query can consume disproportionate resources across the entire database cluster.

Firestore's indexing system adds another layer of complexity. While indexes improve query performance, they don't protect against regex-based attacks. In fact, complex regex patterns can bypass index optimizations entirely, forcing full collection scans.

Another Firestore-specific manifestation occurs in security rules. When rules use regex to validate document IDs or field values, crafted patterns can cause the rule evaluation to timeout:

match /databases/{database}/documents {
  match /users/{userId} {
    allow read, write: if userId.matches(req.auth.uid) 
  }
}

If an attacker can influence req.auth.uid or the document structure, they could trigger expensive regex evaluations in the security layer itself.

Detecting ReDoS vulnerabilities in Firestore requires both static analysis and runtime monitoring. The middleBrick API security scanner specifically tests for this issue by analyzing your Firestore queries and security rules.

middleBrick's detection methodology includes:

• Pattern analysis: Scanning for regex operations that use user-controlled input without validation
• Query structure analysis: Identifying queries that could trigger expensive regex evaluations
• Security rule analysis: Finding regex patterns in rules that could be exploited
• Runtime simulation: Testing common ReDoS patterns against your API endpoints

For manual detection, look for these red flags in your Firestore code:

// VULNERABLE: Direct user input to regex
const pattern = req.query.search;
const results = await db.collection('items')
  .where('name', 'regex', pattern)
  .get();

middleBrick flags this by checking if the regex pattern originates from HTTP parameters, headers, or other untrusted sources. It also tests with known malicious patterns like:

// Common ReDoS test patterns
const evilPatterns = [
  '(a+)+b',           // Exponential backtracking
  '([a-zA-Z]+)*$',    // Nested quantifiers
  '(x+x+)+y',         // Multiple repetitions
];

The scanner runs these patterns through your API endpoints to observe response times and error patterns that indicate regex processing issues.

For security rules, middleBrick analyzes the rule syntax tree to find regex operations that could be triggered by external inputs. It specifically looks for:

• Dynamic regex patterns in allow/deny conditions
• Regex operations on user-controlled variables
• Complex patterns with nested quantifiers or alternations

middleBrick's Firestore-specific checks also verify if your queries are properly indexed and whether regex queries could bypass index optimizations, leading to full collection scans.

Fixing ReDoS vulnerabilities in Firestore requires a multi-layered approach. Here are Firestore-specific remediation strategies:

1. Input Validation and Sanitization

Always validate and sanitize user input before using it in regex operations:

function sanitizeRegexInput(input) {
  // Remove dangerous regex metacharacters
  return input.replace(/[*+?.|^$()[\]{}]/g, '');
}

// Secure version
const safePattern = sanitizeRegexInput(req.query.pattern);
const results = await db.collection('users')
  .where('email', 'regex', safePattern)
  .get();

2. Use Firestore's Text Search Instead of Regex

Firestore's array-contains and in operators are safer alternatives to regex for many use cases:

// Instead of regex search on tags
const tags = req.query.tags.split(',');
const results = await db.collection('posts')
  .where('tags', 'array-contains-any', tags)
  .get();

3. Implement Timeouts and Query Limits

Set reasonable limits on query complexity and execution time:

async function safeFirestoreQuery(collection, field, pattern, options = {}) {
  const { maxComplexity = 1000, timeoutMs = 5000 } = options;
  
  // Check pattern complexity
  const complexity = estimateRegexComplexity(pattern);
  if (complexity > maxComplexity) {
    throw new Error('Query too complex');
  }
  
  // Use a timeout wrapper
  return Promise.race([
    db.collection(collection)
      .where(field, 'regex', pattern)
      .get(),
    new Promise((_, reject) => 
      setTimeout(() => reject(new Error('Query timeout')), timeoutMs)
    )
  ]);
}

4. Secure Security Rules

Avoid dynamic regex in security rules. Use static patterns or other validation methods:

match /databases/{database}/documents {
  match /users/{userId} {
    // Instead of regex, use direct comparison
    allow read, write: if userId == req.auth.uid
  }
  
  match /public/{docId} {
    // Use whitelist approach instead of pattern matching
    allow read: if docId.matches('^[a-z0-9_-]{1,50}$')
  }
}

5. Use MiddleBrick for Continuous Monitoring

Integrate middleBrick into your development workflow to catch ReDoS issues early:

# In your CI/CD pipeline
middlebrick scan https://your-api.com --category regex-dos --fail-on-high

# Or as a GitHub Action
- name: Run middleBrick Scan
  uses: middlebrick/middlebrick-action@v1
  with:
    api-url: ${{ secrets.API_URL }}
    fail-on-severity: high
    categories: regex-dos, boloa

This ensures any new ReDoS vulnerabilities are caught before deployment.