Integrity Failures in Feathersjs with Dynamodb

FeathersJS is a framework that encourages a service-based architecture where each service exposes methods such as create, update, and patch. When backed by DynamoDB, integrity failures arise primarily from the mismatch between FeathersJS’s flexible payload handling and DynamoDB’s strict attribute definitions and conditional write requirements. Unlike relational databases, DynamoDB does not enforce schema-level constraints such as foreign keys or mandatory columns at the database layer. This shifts the burden to the application to enforce data integrity, and if FeathersJS services omit explicit checks, clients can supply malformed, conflicting, or malicious data that is accepted and persisted.

Consider an inventory service where a client calls POST /inventory with a payload that includes expectedDeliveryDate and shipped. Without proper validation, a client could set shipped to true while providing no actual shipment record, creating an integrity inconsistency. FeathersJS hooks can mitigate this, but if they are not configured or are misordered, the unchecked data flows directly into the DynamoDB PutItem or UpdateItem request. Because DynamoDB will accept the write as long as the key schema and capacity limits are respected, the invalid state is stored, leading to logical corruption and potential BOLA/IDOR when other services read this inconsistent data.

DynamoDB’s conditional expressions are designed to enforce integrity at the write level, yet FeathersJS by itself does not automatically translate business rules into conditions such as attribute_not_exists or version checks. For example, if two clients concurrently attempt to update the same item, DynamoDB’s optimistic locking via Version attribute and ConditionalCheckFailedException can prevent lost updates, but only if the FeathersJS service explicitly includes the version check in the update parameters. Without this, the last write wins, which may violate business integrity rules such as “status cannot move from cancelled to completed.” Additionally, DynamoDB’s sparse index design can exacerbate integrity issues: if a secondary index is not updated atomically with the base table, queries against the index return results that do not match the source data, creating an integrity mismatch across query paths.

The interaction with DynamoDB’s type system also contributes to integrity failures. FeathersJS often receives JSON with loose typing, whereas DynamoDB distinguishes between NULL, empty strings, and missing attributes. If a FeathersJS service does not sanitize or normalize these distinctions, a field expected to be a number might be stored as a string, breaking downstream numeric comparisons and aggregations. This is especially risky in financial or telemetry systems where numeric integrity is critical. Inadequate input validation in FeathersJS hooks can allow malformed data to pass through, and DynamoDB will store it without complaint, making later retrieval and processing error-prone.

LLM/AI Security checks are relevant here because generated prompts or logs that include malformed API payloads could expose structural details about the DynamoDB schema, aiding an attacker in crafting precision attacks. System prompt leakage detection and active prompt injection testing help ensure that AI-assisted development or logging does not inadvertently reveal service-specific integrity constraints that could be exploited to bypass validation.

Remediation centers on enforcing integrity at the FeathersJS service layer before issuing DynamoDB requests, and leveraging DynamoDB’s native conditional writes and validation patterns. The following examples assume the use of the AWS SDK for JavaScript v3 and a FeathersJS service hook structure.

1. Enforce mandatory fields and type normalization in a before hook

Use a FeathersJS before hook to validate and normalize payloads. This ensures only correct data reaches DynamoDB.

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

function validateInventoryData(data) {
  if (typeof data.quantity !== 'number' || data.quantity < 0) {
    throw new Error('Invalid quantity');
  }
  if (!data.sku || typeof data.sku !== 'string') {
    throw new Error('Missing or invalid SKU');
  }
  if (data.shipped === true && !data.trackingId) {
    throw new Error('Tracking ID required when shipped is true');
  }
  return data;
}

module.exports = {
  before: {
    create: [context => {
      context.data = validateInventoryData(context.data);
      // Normalize NULL/empty string distinctions
      if (context.data.notes === undefined) {
        context.data.notes = { NULL: true };
      }
      return context;
    }],
    update: [context => {
      context.data = validateInventoryData(context.data);
      return context;
    }],
  },
};

2. Use conditional writes for status transitions and concurrency control

DynamoDB conditional expressions prevent invalid state changes. In a FeathersJS update hook, construct an update expression with conditions.

const ddb = new DynamoDB({ region: 'us-east-1' });

async function updateStatusWithCondition(id, newStatus, expectedCurrentStatus, version) {
  const params = {
    TableName: 'Inventory',
    Key: marshall({ id }),
    UpdateExpression: 'SET #status = :newStatus, #version = :version',
    ConditionExpression: '#status = :expectedCurrentStatus AND #version = :version',
    ExpressionAttributeNames: {
      '#status': 'status',
      '#version': 'version',
    },
    ExpressionAttributeValues: {
      ':newStatus': { S: newStatus },
      ':expectedCurrentStatus': { S: expectedCurrentStatus },
      ':version': { N: String(version) },
    },
    ReturnValues: 'UPDATED_NEW',
  };

  try {
    const result = await ddb.updateItem(params);
    return unmarshall(result.Attributes);
  } catch (error) {
    if (error.name === 'ConditionalCheckFailedException') {
      throw new Error('Concurrency conflict or invalid status transition');
    }
    throw error;
  }
}

3. Atomic index updates via transactions for multi-table integrity

When a write must update both a base table and a local secondary index, use DynamoDB transactions to ensure atomicity.

async function createInventoryWithIndex(item) {
  const params = {
    TransactItems: [
      {
        Put: {
          TableName: 'Inventory',
          Item: marshall({
            sku: item.sku,
            quantity: { N: String(item.quantity) },
            status: { S: item.status },
            version: { N: '0' },
          }),
        },
      },
      {
        Put: {
          TableName: 'InventoryIndex',
          Item: marshall({
            sku: item.sku,
            warehouseId: { S: item.warehouseId },
            quantity: { N: String(item.quantity) },
          }),
        },
      },
    ],
  };

  try {
    const result = await ddb.transactWriteItems(params);
    return unmarshall(result.Responses[0].Put.Item);
  } catch (error) {
    // Handle TransactionCanceledException for atomic rollback
    throw new Error('Transaction failed, integrity not preserved');
  }
}

4. Prevent BOLA/IDOR with explicit ownership checks in after hooks

Even with DynamoDB keys, ensure that a user can only access their own data by validating ownership in after hooks before returning results.

function enforceOwnership(afterHook) {
  return async context => {
    const result = await afterHook(context);
    if (Array.isArray(result)) {
      return result.filter(item => item.userId === context.params.user.id);
    }
    if (result && result.userId !== context.params.user.id) {
      throw new Error('Unauthorized access');
    }
    return result;
  };
}

// Usage in service configuration
service.hooks.push({
  after: {
    find: enforceOwnership(async context => {
      const params = {
        TableName: 'Inventory',
        KeyConditionExpression: 'userId = :uid',
        ExpressionAttributeValues: {
          ':uid': { S: context.params.user.id },
        },
      };
      const data = await ddb.query(params);
      return data.Items.map(unmarshall);
    }),
  },
});

5. Continuous monitoring and schema-aware validation

For ongoing integrity, combine DynamoDB’s DescribeTable to understand key schema with runtime validation libraries that enforce numeric ranges, enum values, and string patterns. This reduces the risk of schema drift causing silent corruption.