Side Channel Attack in Express with Dynamodb

A side channel attack in an Express service that uses DynamoDB does not exploit a flaw in DynamoDB itself, but rather leaks information through timing or error behavior in how Express routes interact with DynamoDB. For example, an attacker can probe authentication or lookup endpoints and infer whether a user exists based on response time differences between existing and non-existing items. If route handlers perform early returns for missing items and skip subsequent operations like condition checks or secondary index lookups, the reduced processing time reveals information.

Consider an Express route that retrieves a user by email and conditionally fetches a profile only when the user exists. If the DynamoDB getItem for a missing email returns almost instantly while a valid item triggers an additional query or scan on a GSI, the timing discrepancy exposes the existence of the email. This becomes actionable when combined with other DynamoDB behaviors, such as variable latency from strongly consistent reads versus eventually consistent reads, or differences caused by item size and index usage.

Error handling patterns also contribute. Distinct error messages for missing items versus malformed conditions or provisioned throughput exceptions give away which part of the flow failed. For instance, a ResourceNotFoundException versus a ConditionalCheckFailedException tells an attacker that the item existed but the condition did not pass. If the Express app uses the AWS SDK for JavaScript and does not normalize responses, these signals leak through HTTP status codes and response bodies, enabling enumeration attacks such as username or email harvesting.

In multi-tenant scenarios, side channels can expose tenant boundaries. If DynamoDB queries filter by a tenant identifier that is sometimes omitted due to logic bugs, the timing of index misses or empty result sets can reveal whether a tenant has any data. This is particularly relevant when combined with features like DynamoDB Accelerator (DAX) cache timing differences, where cache hits may respond faster than misses that fall back to the primary table.

To assess this with middleBrick, an unauthenticated scan of an Express endpoint that relies on DynamoDB can surface timing inconsistencies and error handling patterns that indicate a side channel. The scan’s input validation and property authorization checks highlight places where responses differ based on data existence, while findings related to authentication and BOLA/IDOR point to insufficient isolation that can amplify side channel risks.

Remediation centers on making operations indistinguishable in timing and error behavior, and avoiding reliance on error types to reveal internal state. Use constant-time patterns where possible and normalize responses so that the client receives the same structure regardless of whether an item exists.

First, avoid early returns that skip DynamoDB work. Instead, execute a lightweight query or getItem for every path and ensure the handler performs a similar amount of processing. For example, if an email does not exist, still run a conditional read against a placeholder or perform a dummy query that consumes comparable time.

const AWS = require('aws-sdk');
const dynamo = new AWS.DynamoDB.DocumentClient();
const express = require('express');
const app = express();

app.get('/users/:email', async (req, res) => {
  const email = req.params.email;
  try {
    const baseParams = {
      TableName: process.env.USERS_TABLE,
      Key: { email }
    };
    const data = await dynamo.get(baseParams).promise();
    // Always perform a secondary operation to normalize timing
    if (!data.Item) {
      // Perform a low-cost dummy query on a global secondary index to consume time
      await dynamo.query({
        TableName: process.env.USERS_TABLE,
        IndexName: 'email-index',
        KeyConditionExpression: 'email = :email',
        ExpressionAttributeValues: { ':email': 'dummy@nonexistent.invalid' }
      }).promise();
      return res.status(200).json({ exists: false });
    }
    // Normal response shape for existing items
    res.status(200).json({ exists: true, user: data.Item });
  } catch (err) {
    // Normalize error responses to avoid leaking internal state
    res.status(200).json({ exists: false });
  }
});

Second, standardize error handling to avoid exposing ConditionalCheckFailedException or ResourceNotFoundException. Map all errors to a generic response shape and use the same HTTP status code for client-not-found scenarios. This prevents attackers from inferring existence based on error codes.

app.get('/profile/:userId', async (req, res) => {
  const userId = req.params.userId;
  try {
    const data = await dynamo.get({
      TableName: 'profiles',
      Key: { userId }
    }).promise();
    if (!data.Item) {
      return res.status(200).json({ found: false });
    }
    res.status(200).json({ found: true, profile: data.Item });
  } catch (err) {
    // Never expose err.code or err.message to the client
    res.status(200).json({ found: false });
  }
});

Third, consider using DynamoDB strongly consistent reads only where necessary, and document how this interacts with timing. While consistency mode does not prevent side channels, understanding latency differences helps in designing compensating controls. Combine this with rate limiting at the Express layer to reduce the signal an attacker can gather through repeated requests.

Finally, validate and sanitize all inputs before they reach DynamoDB conditions to avoid leaking information through exception paths. Ensure that malformed payloads do not produce distinct error classes that an attacker can differentiate. The middleBrick CLI can be used in your pipeline to verify that endpoints do not present timing or error-based leakage by running scans against staging URLs and reviewing findings related to authentication and input validation.