Regex Dos in Express with Dynamodb

Regular expression denial-of-service (Regex DoS) occurs when a pattern exhibits catastrophic backtracking on crafted input. In Express applications that use DynamoDB as a backend, composing complex regular expressions over untrusted request parameters and then using those expressions to validate or transform data before issuing DynamoDB operations can amplify risk. Two dimensions interact: the Express request handling path and the DynamoDB client behavior.

First, consider an endpoint that accepts a user-supplied filter pattern and uses it to validate or transform a string before building a DynamoDB query. If the regular expression is not carefully constrained, an attacker can provide input that causes exponential backtracking during regex execution. Because Express typically handles each request on the event loop, a single malicious request can occupy the event loop long enough to degrade responsiveness for other requests. This does not require access to DynamoDB; the impact occurs during validation before any database call.

Second, DynamoDB-specific patterns can inadvertently encourage unsafe usage. For example, developers sometimes construct a parameter that is intended for use only after validation, but they perform validation using a regex and then pass the raw user input into DynamoDB operations such as GetItem or Query. If the regex is weak or poorly anchored, an attacker can cause heavy CPU consumption during regex evaluation. Moreover, if the regex is used to construct or sanitize a key condition expression or filter expression, malformed input can lead to repeated failed queries that still consume resources on both the application and the database client layer.

A concrete scenario: an Express route accepts a username path parameter and uses a regex to ensure it contains only alphanumeric characters before using it in a DynamoDB GetItem key. A regex like /^[a-zA-Z0-9]+$/ is generally safe, but a more complex pattern with nested quantifiers, such as /^(a+)+$/ on untrusted input, can exhibit catastrophic backtracking. Even if the regex passes, failing to anchor patterns with ^ and $ can cause the engine to explore many partial matches, increasing processing time. Because DynamoDB operations are asynchronous and involve network calls, the overall request latency can increase further if the event loop is blocked by the regex, creating a compounded denial-of-service effect under load.

To detect this risk profile, middleBrick scans Express endpoints that include regex-based validation and flags patterns that use nested quantifiers or lack explicit bounds. It also checks whether user input flows into DynamoDB operations without strict normalization, highlighting where untrusted data reaches database client calls. This helps teams understand how regex choices in Express can indirectly stress DynamoDB interactions by increasing error paths and failed query attempts.

Remediation focuses on avoiding complex, user-influenced regular expressions and ensuring DynamoDB operations are resilient to malformed input. Prefer simple, linear checks or use built-in validation libraries that avoid backtracking pitfalls. When you must use regular expressions, keep them simple, anchored, and non-overlapping.

Example of a vulnerable Express route with a problematic regex and unsafe DynamoDB usage:

const express = require('express');
const AWS = require('aws-sdk');
const app = express();

const dynamo = new AWS.DynamoDB.DocumentClient();

app.get('/user/:username', (req, res) => {
  const username = req.params.username;
  // Vulnerable regex with nested quantifiers
  const pattern = /^(a+)+$/;
  if (!pattern.test(username)) {
    return res.status(400).send('Invalid username');
  }
  const params = {
    TableName: 'Users',
    Key: { username: username }
  };
  dynamo.get(params, (err, data) => {
    if (err) return res.status(500).send('Database error');
    res.json(data.Item);
  });
});

The regex /^(a+)+$/ can cause catastrophic backtracking on crafted input like "a" + '!'.repeat(5000) (with overlapping quantifiers). Replace it with a linear check or a simpler anchored pattern:

Safer validation using a simple character class and length limits:

const express = require('express');
const AWS = require('aws-sdk');
const app = express();

const dynamo = new AWS.DynamoDB.DocumentClient();

app.get('/user/:username', (req, res) => {
  const username = req.params.username;
  // Simple, safe validation: alphanumeric, length bounds
  if (!/^[a-zA-Z0-9]{1,64}$/.test(username)) {
    return res.status(400).send('Invalid username');
  }
  const params = {
    TableName: 'Users',
    Key: { username: username }
  };
  dynamo.get(params, (err, data) => {
    if (err) return res.status(500).send('Database error');
    res.json(data.Item);
  });
});

For more complex validation needs, use a dedicated validation library to avoid writing regexes manually, and ensure that any regular expressions are compiled once and reused rather than constructed per request. In DynamoDB operations, always validate and sanitize inputs before constructing key condition expressions, and prefer parameterized queries to avoid injection-related retries that can amplify resource consumption.

middleBrick’s scans can be integrated into your workflow via the CLI (middlebrick scan <url>), the GitHub Action to fail builds on risky patterns, or the MCP Server for IDE-integrated checks. These integrations help catch regex-related issues before they reach production, reducing the chance of Regex DoS affecting your Express and DynamoDB stack.