Regex Dos in Express with Api Keys

A Regular Expression Denial of Service (ReDoS) occurs when an attacker can supply input that causes a regular expression to take an excessive amount of time to evaluate. In Express applications that rely on API keys exposed in URLs, headers, or query parameters, ReDoS can be triggered through crafted strings that force catastrophic backtracking. This is particularly relevant when API key validation is performed using regular expressions rather than constant-time comparison methods.

Consider an Express route that validates an API key using a pattern such as ^(a+)+$ to enforce that the key contains only the letter a and must contain at least one a. If an attacker sends a long string like aaaa...aaa!, the regex engine may engage in extensive backtracking as it tries to match the (a+)+ pattern against the invalid trailing character. This can cause the event loop to block for seconds, leading to resource exhaustion and degraded service for all requests.

When API keys are embedded in URL paths, such as /api/:apiKey/resource, and validated with a vulnerable regex, the risk is compounded. An attacker can probe the endpoint with specially crafted keys that exploit overlapping quantifiers, such as (a|aa)*, which is known to be susceptible to exponential time complexity. Because the scan categories performed by middleBrick include Input Validation, such patterns are surfaced as findings, highlighting the need to avoid complex regexes for key validation.

In the context of API key management, ReDoS can also arise from overly permissive patterns used to accommodate different key formats, such as allowing mixed alphanumeric characters with loose repetition rules. For example, a pattern like [A-Za-z0-9]{1,32} is generally safe, but introducing optional groups or alternations without careful consideration can reintroduce catastrophic backtracking. The presence of findings related to Input Validation and Rate Limiting in middleBrick reports often indicates that regex-based validation may be a contributing factor.

Moreover, when API keys are passed as query parameters, such as ?key=SECRET, and processed with regexes for format enforcement, the application may inadvertently amplify the attack surface. An attacker can generate numerous variations of the key parameter with edge-case strings designed to trigger backtracking. Because middleBrick tests the unauthenticated attack surface, such weaknesses in API key handling are detectable through its security checks, emphasizing the importance of using constant-time operations for key comparison rather than regex pattern matching.

To summarize, the combination of Express routes, API key validation, and poorly constructed regular expressions creates a scenario where an attacker can degrade server performance without needing authentication. This aligns with findings that middleBrick reports under Input Validation and Rate Limiting, where inefficient patterns can lead to service disruption. Addressing these issues requires replacing regex-based validation with safer string operations and ensuring that any pattern used is linear in complexity.

To mitigate ReDoS risks associated with API key validation in Express, avoid using regular expressions for key verification. Instead, use constant-time string comparison and strict length and character checks. This ensures that the validation time does not depend on the structure of the input, eliminating opportunities for catastrophic backtracking.

Below is an example of an insecure implementation that uses a vulnerable regex to validate API keys passed in the URL path:

// Insecure: vulnerable to ReDoS
app.get('/api/:apiKey/resource', (req, res) => {
  const pattern = /^(a+)+$/;
  if (pattern.test(req.params.apiKey)) {
    res.send('Valid key');
  } else {
    res.status(401).send('Invalid key');
  }
});

An attacker can send a crafted string such as aaaa...aaa! to trigger excessive backtracking. The following remediation replaces regex validation with a constant-time check that verifies the key format using simple string operations:

// Secure: constant-time validation without regex
const isValidApiKey = (key) => {
  // Accept only alphanumeric keys of fixed length, e.g., 32 characters
  if (key.length !== 32) return false;
  for (let i = 0; i < key.length; i++) {
    const code = key.charCodeAt(i);
    if (!(
      (code >= 48 && code <= 57) || // 0-9
      (code >= 65 && code <= 90) || // A-Z
      (code >= 97 && code <= 122)    // a-z
    )) {
      return false;
    }
  }
  return true;
};

app.get('/api/:apiKey/resource', (req, res) => {
  if (isValidApiKey(req.params.apiKey)) {
    res.send('Valid key');
  } else {
    res.status(401).send('Invalid key');
  }
});

For API keys passed as headers, you can implement similar safe validation. The following example shows how to validate a header value without using regex patterns that may cause ReDoS:

// Secure: header validation using constant-time checks
app.get('/api/resource', (req, res) => {
  const apiKey = req.headers['x-api-key'];
  if (typeof apiKey !== 'string' || apiKey.length !== 32) {
    return res.status(401).send('Invalid key');
  }
  // Further constant-time checks can be applied here
  res.send('Valid key');
});

When using the middleBrick CLI to scan your Express endpoints, findings related to Input Validation will highlight patterns that may still rely on complex regexes. The CLI output can guide you toward replacing these with safer alternatives. Additionally, integrating the GitHub Action ensures that such issues are caught before deployment, enforcing secure validation practices across your CI/CD pipeline.

Finally, consider centralizing key validation logic to avoid duplication and ensure consistent behavior. Using environment variables to store expected key characteristics (such as length and allowed character sets) can further simplify safe validation. The MCP Server integration allows you to run scans directly from your IDE, helping you identify risky patterns early in development.