Insecure Design in Feathersjs with Dynamodb

Insecure design in a FeathersJS service backed by DynamoDB often stems from modeling data in a way that encourages broad read access and weak ownership checks, then relying on runtime checks alone. A typical pattern is a single DynamoDB table keyed by tenant or user ID, with the service layer accepting an ID parameter and performing a get or query without validating that the requesting user is authorized for that specific item. Because DynamoDB is a low-level, high-throughput store, it does not enforce row-level permissions; it is the application layer in FeathersJS that must enforce this. If the service maps incoming identifiers (e.g., :id) directly to DynamoDB keys without scoping to the requester, an attacker can enumerate or manipulate IDs to access other users' data, effectively a BOLA/IDOR via insecure design.

FeathersJS encourages a service-oriented architecture where services define find and get methods. When these services are implemented to issue DynamoDB operations based on parameters supplied by the client without additional context, the design becomes vulnerable. For example, a find that runs a query on a global secondary index without filtering by the authenticated subject can return multiple records belonging to other tenants or users. Similarly, a get that uses the client-supplied ID as the primary key can retrieve a sensitive record if the ID is predictable or leaked. This is an insecure design choice because it trusts the client to provide correct ownership information, rather than embedding the requester identity into the DynamoDB query expression.

The interaction with DynamoDB amplifies the impact of insecure design decisions. DynamoDB's permission model is limited to IAM policies at the table or item level; it does not understand application-level roles or multi-tenant boundaries. If the service uses a shared credential context (for example, a Lambda role with broad read access), a compromised service or an insecure service implementation can read or scan across partitions belonging to other users. Poor key design—such as using a global sort key that does not incorporate tenant or user context—makes it difficult to enforce isolation with query filters alone. Attack patterns like IDOR or BOLA become realistic when the data model does not enforce ownership at the partition key design stage, and FeathersJS routes expose those keys directly.

Consider an insecure FeathersJS service that accepts an _id from the client and performs a DynamoDB get:

app.use('messages', {
  async get(id) {
    const params = {
      TableName: process.env.MESSAGES_TABLE,
      Key: {
        id: { S: id }
      }
    };
    const { Item } = await dynamodb.get(params).promise();
    if (!Item) {
      throw new Error('Not found');
    }
    return Item;
  }
});

In this design, the id is taken directly from the request. An attacker who knows or guesses another valid ID can retrieve messages they should not see. A more secure design would scope the query to the authenticated subject by including the user ID as part of the key or as a filter, and by validating that the retrieved item belongs to the requester before returning it.

Remediation centers on ensuring every DynamoDB operation is scoped to the authenticated subject and that the data model supports efficient isolation. In FeathersJS, this means enriching the service methods with the authenticated user context (e.g., params.user) and using it to constrain DynamoDB requests. Instead of allowing the client to dictate the key, derive the partition key from the user identity and the intended resource type. For example, use a composite primary key such as PK = USER#user_id and SK = MESSAGE#message_id, and require that queries include the user prefix to prevent cross-user reads.

Below is a secure implementation of a FeathersJS service that uses DynamoDB with user-scoped keys. The service extracts the user ID from the authenticated context and builds key expressions that enforce ownership:

app.use('messages', {
  async create(data, params) {
    const userId = params.user && params.user.id;
    if (!userId) {
      throw new Error('Unauthenticated');
    }
    const messageId = generateId(); // e.g., uuid
    const params = {
      TableName: process.env.MESSAGES_TABLE,
      Item: {
        pk: { S: `USER#${userId}` },
        sk: { S: `MESSAGE#${messageId}` },
        content: { S: data.content },
        createdAt: { S: new Date().toISOString() }
      }
    };
    await dynamodb.put(params).promise();
    return { id: messageId, ...data };
  },
  async get(id, params) {
    const userId = params.user && params.user.id;
    if (!userId) {
      throw new Error('Unauthenticated');
    }
    const pk = { S: `USER#${userId}` };
    const sk = { S: `MESSAGE#${id}` };
    const command = new GetCommand({
      TableName: process.env.MESSAGES_TABLE,
      Key: { pk, sk }
    });
    const { Item } = await dynamodb.send(command);
    if (!Item) {
      throw new Error('Not found');
    }
    return { id, content: Item.content?.S };
  },
  async find(params) {
    const userId = params.user && params.user.id;
    if (!userId) {
      throw new Error('Unauthenticated');
    }
    const pk = { S: `USER#${userId}` };
    const command = new QueryCommand({
      TableName: process.env.MESSAGES_TABLE,
      KeyConditionExpression: 'pk = :pk',
      ExpressionAttributeValues: {
        ':pk': pk
      }
    });
    const { Items } = await dynamodb.send(command);
    return Items.map(Item => ({
      id: Item.sk?.S.replace('MESSAGE#', ''),
      content: Item.content?.S
    }));
  }
});

This approach ensures that users can only access items where the partition key matches their identity. For secondary use cases such as administrative views, introduce a separate service with elevated IAM permissions and additional authorization checks, rather than broadening the permissions of the user-scoped service.

When using DynamoDB streams or triggers, maintain the same scoping discipline on the consumer side. Ensure that any asynchronous processing respects the tenant or user context derived from the record keys. Avoid designing a system where a single DynamoDB table is used for multiple tenants without a robust attribute-based access control (ABAC) layer on top, as this increases the risk of insecure design flaws that are hard to audit.

Finally, validate input IDs even when they are combined with user context. Use pattern checks or allow-lists for identifiers to prevent injection-style issues at the application layer, and prefer parameterized queries or command objects to avoid constructing request structures manually. These design choices reduce the likelihood of IDOR and privilege escalation in FeathersJS services backed by DynamoDB.