Beast Attack in Feathersjs with Dynamodb

A Beast Attack (also known as a BOLA or IDOR) in a Feathersjs service backed by DynamoDB occurs when an application exposes item identifiers or weak ownership checks, allowing one authenticated user to read, modify, or delete another user’s data. Feathersjs encourages REST-like routes and hooks that can inadvertently forward client-supplied IDs directly to DynamoDB without verifying that the authenticated subject owns the target record.

DynamoDB itself does not enforce application-level ownership; it stores and retrieves items based on key attributes. If a Feathersjs service uses the client-provided id as the DynamoDB key (e.g., userId or roomId) without cross-checking the authenticated context, a Beast Attack becomes feasible. For example, an API endpoint like /messages/:id might pass :id into a DynamoDB GetItem or Query without confirming the caller’s identity matches the message’s owner. This can map to OWASP API Top 10 A1 (Broken Object Level Authorization) and may be surfaced by middleBrick as a BOLA/IDOR finding.

Feathersjs hooks typically run before service methods, and misconfigured hooks can leak or accept unsafe parameters. If a hook does not sanitize the params.query or the id from the request, an attacker can iterate through plausible IDs and enumerate or tamper with other users’ data stored in DynamoDB. middleBrick tests for such unauthenticated or insufficiently scoped endpoints and flags them as high-severity findings, providing remediation guidance to enforce ownership checks.

Real-world patterns include using unguessable identifiers (e.g., UUIDs) without ownership validation, or constructing DynamoDB KeyConditionExpressions that do not include the user partition key. Without explicit checks, an attacker can supply another user’s UUID and retrieve or modify sensitive records. The scanner does not exploit these but highlights where runtime behavior deviates from secure authorization expectations.

To secure a Feathersjs service with DynamoDB, enforce ownership at the hook level and ensure every data access includes the authenticated subject as part of the key expression. Avoid passing raw client IDs directly as DynamoDB keys without validating that they belong to the requester.

const { AuthenticationError } = require('@feathersjs/errors');
const { DynamoDBDocumentClient, GetCommand } = require('@aws-sdk/lib-dynamodb');

// Example secure hook
async function ensureOwnership(context) {
  const { user } = context.params; // authenticated user added by auth hook
  if (!user || !user.userId) {
    throw new AuthenticationError('Authentication required');
  }
  const id = context.id;
  // Ensure the client-supplied id contains the user partition, or replace it
  if (!id || typeof id !== 'string') {
    throw new Error('Invalid resource id');
  }
  // Reconstruct the DynamoDB key with the user as partition key
  const itemKey = { userId: user.userId, id };
  context.params.dynamoItemKey = itemKey;
  return context;
}

// Service method using the secured key
const client = DynamoDBDocumentClient.from(new DynamoDBClient({}));
app.use('/messages', {
  async get(id, params) {
    const key = params.dynamoItemKey || { userId: params.user.userId, id };
    const command = new GetCommand({ TableName: 'Messages', Key: key });
    const response = await client.send(command);
    if (!response.Item) {
      throw new NotFound('Message not found');
    }
    return response.Item;
  },
  hooks: {
    before: {
      all: [ensureOwnership],
      find: [async context => {
        // For list operations, inject the user partition into the query
        context.params.dynamoQuery = {
          TableName: 'Messages',
          IndexName: 'userByTimestamp-index',
          KeyConditionExpression: 'userId = :uid',
          ExpressionAttributeValues: { ':uid': context.params.user.userId }
        };
        return context;
      }]
    },
    after: []
  }
});

In this pattern, the authenticated user’s ID is always part of the DynamoDB key, preventing cross-user access. The ensureOwnership hook replaces or validates the ID and stores a safe key in context.params.dynamoItemKey. For list queries, use a Global Secondary Index keyed by userId and filter by userId = :uid to avoid scanning the entire table. middleBrick’s parallel checks for Property Authorization and BOLA/IDOR will validate that such controls are present and effective.

Additionally, avoid using client-provided sequential or guessable IDs as DynamoDB partition keys without ownership scoping. Instead, generate UUIDs on the server or combine user identifiers into composite keys. Configure your DynamoDB table’s key schema to align with these access patterns, and ensure that every data retrieval includes the user context. middleBrick’s OpenAPI/Swagger analysis can detect missing security schemes or insufficient path parameter scoping that would otherwise enable Beast Attacks.

Remediation guidance from findings typically includes adding mandatory ownership checks in before-hooks, tightening route parameters, and validating that DynamoDB KeyConditionExpression or FilterExpression always includes the authenticated user’s identity. Do not rely on client-supplied roles or claims alone; enforce constraints at the data access layer.