Race Condition in Feathersjs with Dynamodb

A race condition in a FeathersJS service backed by DynamoDB occurs when multiple concurrent requests read and write shared data without effective synchronization, leading to lost updates or inconsistent state. This specific combination is vulnerable because DynamoDB’s conditional writes and transactions must be explicitly used; default CRUD calls in FeathersJS do not enforce strong consistency for check-then-act patterns. For example, consider a ticket reservation service where a client reads remaining seats, calculates availability, and then writes the updated count. Between the read and the write, another request can perform the same read, resulting in both requests writing based on stale data and overselling seats.

In FeathersJS, services are often implemented with hooks that perform reads (e.g., app.service('tickets').Model.get(id)) followed by writes (e.g., app.service('tickets').Model.update(id, patch)) without atomic guards. DynamoDB’s eventual consistency for reads can exacerbate this: a read might not reflect a recently committed write from another request, causing the conditional update to incorrectly pass or fail. If conditional writes are omitted, concurrent operations can overwrite each other. A common anti-pattern is implementing a ‘vote’ endpoint that reads a vote count, increments it, and writes back, without using DynamoDB’s atomic add or conditional expressions. This creates a classic time-of-check-to-time-of-use (TOCTOU) window that an attacker can exploit via parallel requests, a pattern observed in CWE-367 and relevant to OWASP API Top 10:2023 Broken Object Level Authorization when object state is mishandled.

Real-world examples include inventory decrement, balance transfers, and seat booking. For instance, if a payment service reads a user’s balance, checks sufficiency, and then decrements without an atomic conditional update, two concurrent payments can both proceed despite insufficient funds. DynamoDB best practice is to use UpdateItem with an UpdateExpression and ConditionExpression to make the check-and-set atomic. In FeathersJS, this means moving the condition into the database operation rather than performing it in application logic. Without this, the API surface remains susceptible to race conditions, and findings from middleBrick may flag missing condition expressions as a high-severity issue tied to BOLA/IDOR and Property Authorization checks.

To remediate race conditions in FeathersJS with DynamoDB, use atomic update operations with condition expressions and leverage DynamoDB transactions where multiple items must be consistent. Below are concrete, working examples for FeathersJS services.

1. Atomic increment with condition (seat reservation)

This approach uses UpdateItem to read-modify-write in a single, atomic operation, avoiding the need for a separate read step.

const feathers = require('@feathersjs/feathers');
const {DynamoDBDocumentClient, UpdateCommand} = require('@aws-sdk/lib-dynamodb');
const ddbClient = DynamoDBDocumentClient.from(new AWS.DynamoDB());

app.service('tickets').Model = {
  async patch(id, data) {
    const { available } = data;
    const command = new UpdateCommand({
      TableName: 'tickets_table',
      Key: { id },
      UpdateExpression: 'SET available = available - :dec',
      ConditionExpression: 'available >= :dec',
      ExpressionAttributeValues: { ':dec': available },
      ReturnValues: 'UPDATED_NEW'
    });
    try {
      const { Attributes } = await ddbClient.send(command);
      return Attributes;
    } catch (error) {
      if (error.name === 'ConditionalCheckFailedException') {
        throw new errors.GeneralError('Insufficient seats available', { code: 409 });
      }
      throw error;
    }
  }
};

2. Transactional updates for related entities (balance transfer)

When multiple items must be updated together, use a DynamoDB transaction to ensure all-or-nothing semantics.

app.service('accounts').Model = {
  async patch(id, data) {
    const { targetId, amount } = data;
    const transactItems = [
      {
        Update: {
          TableName: 'accounts_table',
          Key: { id: { S: id } },
          UpdateExpression: 'SET balance = balance - :amt',
          ConditionExpression: 'balance >= :amt',
          ExpressionAttributeValues: { ':amt': { N: amount.toString() } }
        }
      },
      {
        Update: {
          TableName: 'accounts_table',
          Key: { id: { S: targetId } },
          UpdateExpression: 'SET balance = balance + :amt',
          ExpressionAttributeValues: { ':amt': { N: amount.toString() } }
        }
      }
    ];
    try {
      const { Responses } = await ddbClient.transactWriteItems({ TransactItems: transactItems });
      return Responses;
    } catch (error) {
      if (error.name === 'TransactionCanceledException') {
        throw new errors.GeneralError('Transfer failed due to insufficient funds or concurrent modification', { code: 409 });
      }
      throw error;
    }
  }
};

3. Using optimistic locking with a version attribute

If your data model includes a version number or timestamp, include it in a condition to detect collisions.

app.service('profiles').Model = {
  async update(id, data, params) {
    const { email, _version } = data;
    const command = new UpdateCommand({
      TableName: 'profiles_table',
      Key: { id },
      UpdateExpression: 'SET email = :email, _version = _version + :one',
      ConditionExpression: '_version = :version',
      ExpressionAttributeValues: {
        ':email': email,
        ':version': _version,
        ':one': 1
      },
      ReturnValues: 'UPDATED_NEW'
    });
    try {
      const { Attributes } = await ddbClient.send(command);
      return Attributes;
    } catch (error) {
      if (error.name === 'ConditionalCheckFailedException') {
        throw new errors.GeneralError('Concurrent modification detected', { code: 409 });
      }
      throw error;
    }
  }
};

These patterns ensure that checks and mutations are performed atomically on the server side, closing the race condition window. middleBrick scans can help identify missing condition expressions and inconsistent use of transactions, providing findings mapped to OWASP API Top 10 and compliance frameworks.