Bola Idor in Nestjs with Dynamodb

Broken Object Level Authorization (BOLA) occurs when an API exposes object identifiers and fails to enforce that the authenticated subject is authorized to access the specific resource. In a NestJS service that uses DynamoDB as the persistence layer, BOLA commonly arises when an endpoint accepts a user-controlled identifier (e.g., a ticket ID or user ID) and issues a GetItem or Query operation without confirming that the item belongs to the requester.

Consider a typical NestJS controller and service pattern:

@Get(':id')
async getTicket(@Param('id') id: string, @Req() req: Request): Promise<any> {
  return this.ticketsService.getTicket(id, req.user.sub);
}

If the service directly uses the id parameter in a DynamoDB GetItem request without verifying ownership, an attacker can simply iterate or guess IDs and access other users’ tickets. DynamoDB’s key-based model makes this especially easy to exploit: with a primary key (partition key, and optionally sort key) in hand, a GetItem is inexpensive and fast, and there is no built-in ownership check.

Common patterns that lead to BOLA with DynamoDB in NestJS include:

• Using a user ID as the partition key but failing to include the user ID in the key expression, e.g., reading by ticketId alone.
• Using a composite key where the sort key encodes user context but the service does not enforce that context on reads or queries.
• Exposing internal identifiers (e.g., DynamoDB item keys) directly to the client without a mapping or access check.

Because the scan is unauthenticated, middleBrick’s BOLA checks attempt to retrieve resources using known identifiers without providing valid authorization context and then attempt to access other users’ resources by modifying identifiers. In DynamoDB terms, this maps to attempts to read items by key without the required partition key ownership or by assuming predictable sort key structures.

Real-world attack patterns aligned with this vulnerability include horizontal privilege escalation (accessing same-level resources of other users) and vertical escalation when the identifier leaks admin or privileged items. Findings from such scans are mapped to the OWASP API Top 10 (2023) A01:2019 — Broken Object Level Authorization.

Remediation centers on ensuring that every data access operation includes the authorization context of the requester and that identifiers are either not exposed directly or are guarded by access checks.

1. Always include the user’s partition key in the key expression. If your table uses PK as the partition key and stores user-based access as a prefix, enforce it explicitly:

import { DynamoDB } from "aws-sdk";

const getItemParams = {
  TableName: process.env.TICKETS_TABLE,
  Key: {
    PK: { S: `USER#${userId}` }, // ensure the requester’s user ID is part of the key
    SK: { S: `TICKET#${ticketId}` },
  },
};

const data = await this.dynamoDb.get(getItemParams).promise();
if (!data.Item || data.Item.PK.S !== `USER#${userId}`) {
  throw new NotFoundException('Ticket not found or access denied');
}
return data.Item;

2. Avoid using client-supplied IDs directly as keys. Use a service-side mapping or augment keys with tenant/user prefixes and validate on read:

async getTicketWithOwnershipCheck(ticketId: string, userId: string) {
  // PK/SK pattern enforces ownership
  const pk = `USER#${userId}`;
  const sk = `TICKET#${ticketId}`;

  const params = {
    TableName: process.env.TICKETS_TABLE,
    Key: { PK: { S: pk }, SK: { S: sk } },
  };

  const result = await this.dynamoDb.get(params).promise();
  if (!result.Item) {
    throw new NotFoundException('Ticket not found');
  }
  // Double-check ownership (redundant but safe)
  if (result.Item.PK?.S !== pk) {
    throw new ForbiddenException('Insufficient permissions');
  }
  return result.Item;
}

3. When using Query, always include the user prefix in the partition key condition and avoid scanning entire indexes:

async listUserTickets(userId: string) {
  const params = {
    TableName: process.env.TICKETS_TABLE,
    IndexName: 'GSI_USER_TICKETS', // optional, if using GSI
    KeyConditionExpression: 'PK = :pk AND begins_with(SK, :skPrefix)',
    ExpressionAttributeValues: {
      ':pk': { S: `USER#${userId}` },
      ':skPrefix': { S: 'TICKET#' },
    },
  };
  const result = await this.dynamoDb.query(params).promise();
  return result.Items || [];
}

4. If you must expose a client-friendly identifier, maintain a mapping table or use a hash that cannot be reversed without context, and validate ownership on each request. Do not rely on obscurity.

5. For scans that must operate across user boundaries (admin operations), require a separate elevated authorization path and do not use the same endpoints or key patterns as user-facing calls.

These patterns ensure that every DynamoDB request includes the requester’s authorization context, neutralizing the BOLA vector by making object references insufficient without proof of ownership.