Race Condition in Express with Dynamodb

A race condition in an Express service that uses DynamoDB typically occurs when multiple requests read and write the same item without coordination, and the application logic depends on the outcome of a read before a write. Because DynamoDB is a eventually consistent key-value store, a read that immediately follows a write might not return the updated value if the write has not yet propagated, depending on your consistency settings. This behavior can be exploited in Express routes that implement patterns like check-then-act or read-modify-write without using conditional writes.

Consider an Express route that processes a payment and attempts to ensure a user has sufficient balance. The route reads the current balance from DynamoDB, performs arithmetic in JavaScript, and then writes the new balance back. If two requests arrive concurrently, both reads may see the same old balance, each compute a new balance, and each write back their result. The last write wins, potentially allowing overspending or double-spending, which is a classic time-of-check-to-time-of-use (TOCTOU) race condition.

When using the DynamoDB Document Client in Express, developers sometimes omit ConditionExpression in put or update operations, relying only on application-level checks. Without a conditional write, concurrent requests can interleave in problematic ways. For example, one request reads { balance: 100 }, another reads { balance: 100 }, both subtract 80, and both write { balance: 20 }. The expected final balance should be 20 if only one withdrawal succeeds, but due to the race the invalid state 20 can persist. This maps to OWASP API Top 10:2023 Broken Object Level Authorization (BOLA) and can enable privilege escalation or unauthorized transactions.

DynamoDB’s conditional writes and transactions exist to prevent these interleavings, but they must be used explicitly. Express applications that do not leverage ConditionExpression or TransactWriteItems expose an unauthenticated or weakly authenticated attack surface where an attacker can send many rapid requests to trigger the race. In black-box scanning, middleBrick’s BOLA/IDOR and BFLA/Privilege Escalation checks look for missing conditions on state-changing operations, and this pattern would likely be flagged with remediation guidance to use conditional updates.

Additionally, if your Express API exposes an endpoint that is also an unauthenticated LLM endpoint, the race condition can be chained with prompt injection or cost exploitation to amplify abuse, for example by causing repeated side effects that incur repeated DynamoDB writes. middleBrick’s LLM/AI Security checks specifically test for such combinations by probing for unauthenticated LLM endpoints and inspecting outputs for side effects, underscoring the importance of securing both the API and the AI integration layer.

To remediate race conditions in Express when using DynamoDB, prefer conditional writes and atomic updates, and avoid read-modify-write patterns unless protected by transactions. Below are concrete, realistic Express code examples that demonstrate safe patterns.

1) Use UpdateItem with ConditionExpression for balance checks. This ensures the update only succeeds if the current value matches the expected value, making the operation atomic on the server side.

const { DynamoDBClient, UpdateCommand } = require('@aws-sdk/client-dynamodb');
const { marshall, unmarshall } = require('@aws-sdk/util-dynamodb');

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

app.post('/withdraw', async (req, res) => {
  const { userId, amount } = req.body;
  const expectedBalance = req.headers['x-balance-version']; // optional optimistic lock
  const params = {
    TableName: 'Accounts',
    Key: marshall({ userId }),
    UpdateExpression: 'SET balance = balance - :amt ADD version :inc',
    ConditionExpression: 'balance >= :minBalance AND (attribute_not_exists(version) OR version = :ver)',
    ExpressionAttributeValues: marshall({
      ':amt': amount,
      ':minBalance': 0,
      ':inc': 1,
      ':ver': expectedBalance ?? 0
    }),
    ReturnValues: 'UPDATED_NEW'
  };
  try {
    const data = await client.send(new UpdateCommand(params));
    res.json({ success: true, newBalance: unmarshall(data.Attributes).balance });
  } catch (err) {
    if (err.name === 'ConditionalCheckFailedException') {
      return res.status(409).json({ error: 'Insufficient balance or stale state' });
    }
    res.status(500).json({ error: 'Internal error' });
  }
});

2) Use TransactWriteItems for multi-item consistency. If your operation must read several items and write several items as a single unit, use a transaction to prevent intermediate states and ensure all-or-nothing semantics.

const { DynamoDBClient, TransactWriteCommand } = require('@aws-sdk/client-dynamodb');
const { marshall } = require('@aws-sdk/util-dynamodb');

app.post('/transfer', async (req, res) => {
  const { fromUserId, toUserId, amount } = req.body;
  const params = {
    TransactItems: [
      {
        Update: {
          TableName: 'Accounts',
          Key: marshall({ userId: fromUserId }),
          UpdateExpression: 'SET balance = balance - :amt',
          ConditionExpression: 'balance >= :amt',
          ExpressionAttributeValues: marshall({ ':amt': amount })
        }
      },
      {
        Update: {
          TableName: 'Accounts',
          Key: marshall({ userId: toUserId }),
          UpdateExpression: 'SET balance = balance + :amt',
          ExpressionAttributeValues: marshall({ ':amt': amount })
        }
      }
    ]
  };
  try {
    await client.send(new TransactWriteCommand(params));
    res.json({ success: true });
  } catch (err) {
    if (err.name === 'TransactionCanceledException') {
      return res.status(409).json({ error: 'Transaction failed due to a concurrent update' });
    }
    res.status(500).json({ error: 'Internal error' });
  }
});

3) Avoid long-lived in-memory state and enforce idempotency keys to reduce the impact of retries that can exacerbate races. Express middleware can validate an idempotency key and ensure that repeated requests do not cause additional writes.

const idempotencyMap = new Map(); // in production use a distributed store like DynamoDB
app.post('/dedup-transfer', async (req, res) => {
  const id = req.headers['idempotency-key'];
  if (!id) return res.status(400).json({ error: 'Idempotency key required' });
  if (idempotencyMap.has(id)) return res.json(idempotencyMap.get(id)); // return cached response
  // perform the conditional update as shown earlier
  try {
    const result = await performAtomicUpdate(req.body);
    idempotencyMap.set(id, result);
    res.json(result);
  } catch (err) {
    idempotencyMap.set(id, { error: err.message });
    res.status(err.status || 500).json({ error: err.message });
  }
});

In summary, always use ConditionExpression or TransactWriteItems when correctness depends on the current state, and design Express routes to be idempotent. middleBrick’s Pro plan includes continuous monitoring and can be integrated into your CI/CD pipeline to flag endpoints that lack conditions on state-changing operations, helping you catch regressions before they reach production.