Api Rate Abuse in Express with Dynamodb

Rate abuse in an Express service that uses DynamoDB can occur when request-rate controls are applied only at the HTTP layer while DynamoDB capacity is left unprotected. Without coordinated limits, an attacker can send a high volume of legitimate-looking HTTP requests that each generate multiple DynamoDB operations, consuming read/write capacity, driving up costs, and potentially triggering throttling (HTTP 500/400) that degrades availability for legitimate users.

Express itself does not enforce per-client or per-key concurrency or request-rate limits. If routes directly perform DynamoDB operations such as GetItem, PutItem, UpdateItem, or BatchGetItem, each request consumes provisioned capacity. Without middleware or architectural controls, bursts of traffic can exhaust capacity units, cause throttling exceptions, and amplify the impact of inefficient queries or secondary-index scans. This is especially risky for write-heavy endpoints that consume write capacity units (WCU) quickly, or for read-heavy endpoints that consume read capacity units (RCU) with strongly consistent reads.

The DynamoDB client SDK does not provide built-in rate limiting; it simply executes requests. Therefore, rate abuse protection must be implemented at the application or infrastructure layer in Express. Common patterns include token-bucket or sliding-window counters stored in a fast in-memory store (e.g., Redis) or using API gateway-level throttling. Even with API gateway protections, DynamoDB-side limits remain important because traffic can bypass the gateway (e.g., direct SDK calls from compromised clients or internal services).

DynamoDB-specific abuse vectors include partition-key hot spots that concentrate traffic on a single partition, leading to throttling even when overall capacity is available. An attacker can intentionally target high-cardinality keys or use non-uniform keys to degrade performance. Inefficient queries, such as scans or queries without proper indexes, can consume many RCU per request, enabling a low-rate HTTP attack to exhaust RCU quickly. Cost abuse is also a concern: excessive read/write usage increases billed capacity requirements and can degrade shared-table performance in multi-tenant designs.

Operational signals become critical for detecting abuse: elevated ThrottledRequests metrics, increased ConsumedReadCapacityUnits or ConsumedWriteCapacityUnits, and frequent 500/400 responses under load. Correlation with request identifiers and source IPs helps pinpoint abusive clients. MiddleBrick’s scans can surface missing rate-limiting controls and misconfigured capacity alarms as findings, emphasizing the need for coordinated HTTP and DynamoDB protections.

Remediation combines Express middleware for request-rate limiting with DynamoDB client-side strategies such as adaptive capacity, exponential backoff, and efficient access patterns. Below are concrete examples that you can adapt to your service.

1. Express rate limiting with a Redis store

Use a token-bucket rate limiter that tracks requests per client (e.g., by IP or API key). This reduces the likelihood of overwhelming DynamoDB.

const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');
const redis = require('redis');

const client = redis.createClient({ url: process.env.REDIS_URL });
client.connect().catch(console.error);

const limiter = rateLimit({
  store: new RedisStore({ client }),
  windowMs: 60 * 1000,
  max: 100, // max 100 requests per window per key
  standardHeaders: true,
  legacyHeaders: false,
  keyGenerator: (req) => req.ip
});

app.use('/api/', limiter);

2. Per-key DynamoDB rate handling with exponential backoff

When DynamoDB returns ProvisionedThroughputExceededException or ThrottlingException, implement retries with exponential backoff and jitter. This protects downstream capacity and improves success rates under bursts.

const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const { retryMode } = require('@aws-sdk/middleware-retry');

const client = new DynamoDBClient({
  region: process.env.AWS_REGION,
  requestHandler: {
    handle: async (request, options, callback) => {
      // custom retry logic can be injected here if needed
      return retryMode({})(request, options, callback);
    }
  }
});

async function getItemWithBackoff(tableName, key) {
  const command = new GetItemCommand({ TableName: tableName, Key: key });
  let attempts = 0;
  const maxAttempts = 5;
  while (attempts < maxAttempts) {
    try {
      const response = await client.send(command);
      return response.Item;
    } catch (err) {
      if (err.name === 'ProvisionedThroughputExceededException' || err.name === 'ThrottlingException') {
        const delay = 50 * Math.pow(2, attempts) + Math.random() * 10;
        await new Promise((resolve) => setTimeout(resolve, delay));
        attempts += 1;
        continue;
      }
      throw err;
    }
  }
  throw new Error('Max retries exceeded');
}

3. Efficient queries and avoiding scans

Prefer query over scan, and ensure access patterns align with indexes. Scans consume high RCU and are easy to trigger inadvertently, enabling rate abuse via resource-intensive operations.

const { DynamoDBClient, QueryCommand } = require('@aws-sdk/client-dynamodb');
const client = new DynamoDBClient({ region: process.env.AWS_REGION });

async function queryItems(tableName, indexName, partitionKeyValue, sortKeyCondition) {
  const command = new QueryCommand({
    TableName: tableName,
    IndexName: indexName,
    KeyConditionExpression: 'partitionKey = :pk AND sortKey ' + sortKeyCondition,
    ExpressionAttributeValues: {
      ':pk': { S: partitionKeyValue }
    },
    Limit: 25 // enforce paging limits to control RCU consumption
  });
  const response = await client.send(command);
  return response.Items;
}

4. Adaptive capacity and partition-key design

Spread traffic across multiple partition values to avoid hot partitions. If your access pattern allows, add randomness or salting to keys. Combine with DynamoDB auto scaling to adjust capacity based on load, and monitor ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits to right-size provisioned throughput.

// Example: salting a numeric ID to distribute writes
const saltedKey = `shard${Math.floor(Math.random() * 10)}-${userId}`;
// Use saltedKey as partition key for write-heavy workloads
const putCmd = new PutItemCommand({
  TableName: 'Orders',
  Item: {
    pk: { S: saltedKey },
    sk: { S: orderId },
    data: { S: JSON.stringify(order) }
  }
});
await client.send(putCmd);

5. API-level coordination with infrastructure protections

Use API gateway throttling as a first line of defense, but enforce DynamoDB-side awareness in Express. Combine middleware limits with DynamoDB client best practices to ensure abusive traffic is controlled before it consumes expensive capacity.