Use After Free in Express with Dynamodb

Use After Free (UAF) in an Express service that uses DynamoDB typically arises when application-level objects that reference DynamoDB operations or responses are accessed after they have been logically released or overwritten. Because DynamoDB calls in Node.js are asynchronous, control flow and object lifetimes must be carefully managed to avoid situations where a handler or callback refers to a request-scoped object that has already been reused or mutated for a new request.

Consider an Express route that initiates a DynamoDB getItem, attaches metadata to the in-flight request object, and later uses that object in a callback or downstream middleware. If the request object is reused (for example, by assigning new properties for a subsequent request before the earlier DynamoDB response resolves), the callback may read or write properties on an object that now represents a different transaction. This can lead to leaking one user’s data to another or executing logic based on stale parameters such as a misinterpreted user ID or a forged item key.

Another realistic scenario involves creating a higher-order function that captures a request-specific DynamoDB client configuration or query parameters in a closure. If the closure is stored beyond the request lifecycle—such as in a cache, an event emitter, or a delayed callback—and later invoked, the captured references may point to invalid or overwritten variables. In the context of DynamoDB, this might mean a query meant for one tenant is executed with another tenant’s key condition, or a delete operation uses an item identifier that no longer belongs to the original request context.

Middleware that parses and modifies request objects before they reach route handlers can also introduce UAF when combined with asynchronous DynamoDB operations. For example, if middleware attaches a promise-based wrapper around a DynamoDB call to req.context and later middleware or route handlers assume the context shape remains stable across asynchronous ticks, they may inadvertently operate on resolved or overwritten results. This is particularly risky when using patterns like attaching listener callbacks to the request object that reference request-specific identifiers used as DynamoDB keys.

These issues map to the broader OWASP API Top 10 category of Server-Side Request Forgery and Broken Object Level Authorization, where improper handling of object lifetimes and indirect references leads to security weaknesses. Although DynamoDB itself does not manage object lifetimes in the runtime, the way an Express application structures references to requests, responses, and client calls determines whether a Use After Free condition can be triggered.

To prevent Use After Free patterns when integrating DynamoDB with Express, design request handling so that each asynchronous operation uses immutable, request-scoped data and avoids mutating shared objects after they have been released. Ensure that closures capture values rather than mutable references, and structure your code so that callbacks and middleware do not rely on request properties that may have been overwritten.

Isolate DynamoDB calls per request

Create a fresh context for each request and do not attach mutable state to req that may be overwritten by subsequent middleware. Instead, pass a copy of necessary identifiers explicitly to async functions.

import express from 'express';
import { DynamoDBClient, GetItemCommand } from '@aws-sdk/client-dynamodb';

const app = express();
const client = new DynamoDBClient({ region: 'us-east-1' });

app.get('/items/:id', async (req, res) => {
  const itemId = req.params.id;
  const command = new GetItemCommand({
    TableName: 'ItemsTable',
    Key: { id: { S: itemId } }
  });

  try {
    const response = await client.send(command);
    res.json(response.Item);
  } catch (error) {
    res.status(500).json({ error: 'Failed to fetch item' });
  }
});

This pattern ensures that itemId is captured as a primitive string value in the async function scope, eliminating the risk that req.params will be mutated before the DynamoDB response resolves.

Avoid mutating request-bound promises or callbacks

Do not assign promises or callback functions to req and then reuse or overwrite them. If you must store asynchronous operations, keep them scoped to a local variable or use a Map keyed by request identifiers that are cleaned up after completion.

const pendingOperations = new WeakMap();

app.post('/query', (req, res) => {
  const { tableName, key } = req.body;
  const command = new GetItemCommand({ TableName: tableName, Key: key });

  const promise = client.send(command)
    .then(data => {
      pendingOperations.delete(req);
      return data;
    })
    .catch(err => {
      pendingOperations.delete(req);
      throw err;
    });

  pendingOperations.set(req, promise);

  promise.then(item => res.json(item)).catch(() => res.sendStatus(500));
});

Using WeakMap helps ensure that entries can be garbage collected when the request object is no longer referenced, reducing the chance of holding onto a stale callback that might be invoked with incorrect data.

Validate and sanitize before constructing DynamoDB parameters

Ensure that values used to build DynamoDB command inputs are validated and sanitized within the same request context, and do not reuse objects that may be altered by later middleware.

import { DynamoDBDocumentClient, GetCommand } from '@aws-sdk/lib-dynamodb';

const ddbDocClient = DynamoDBDocumentClient.from(client);

app.get('/profile/:userId', async (req, res) => {
  const userId = req.params.userId;
  // Validate and sanitize userId before using it in DynamoDB command
  if (!/^[a-zA-Z0-9_-]{3,64}$/.test(userId)) {
    return res.status(400).json({ error: 'Invalid user ID' });
  }

  const command = new GetCommand({
    TableName: 'UserProfiles',
    Key: { userId }
  });

  const result = await ddbDocClient.send(command);
  res.json(result.Item);
});

By validating and constructing DynamoDB inputs immediately within the route handler, you avoid accidentally using modified or shared objects in asynchronous callbacks.

Use middleware carefully with async flows

When using middleware that attaches data for downstream DynamoDB calls, ensure the data is copied rather than referenced. Avoid patterns that mutate the same request object across multiple async steps.

app.use((req, res, next) => {
  // Copy necessary identifiers instead of attaching mutable references
  req.internal = {
    requestId: req.id,
    timestamp: Date.now()
  };
  next();
});