Broken Access Control in Strapi with Dynamodb

Broken Access Control in a Strapi service backed by DynamoDB often originates from how policies or controllers construct DynamoDB requests. Strapi’s permission system relies on policies that receive the user context and build query parameters. If these parameters are derived from user-supplied input without strict validation, an attacker can manipulate identifiers to access records that belong to other users or roles.

Consider a typical findOne implementation where the client supplies an id that is directly used to build a DynamoDB key condition without verifying ownership or authorization. Strapi uses a service layer that may look like strapi.entityService.findOne('api::product.product', id). Under the hood, if the DynamoDB data model uses a composite key like PK=USER#${userId} and SK=PRODUCT#${id}, omitting ownership checks means an attacker can enumerate or guess IDs and retrieve other users’ products. This maps directly to the BOLA/IDOR checks in the 12 parallel security checks, where Strapi endpoints with weak authorization surface findings with severity high or critical.

DynamoDB’s schema flexibility can exacerbate the issue. For example, if a GSI is used to index attributes like status or tenantId, and the application queries the GSI without enforcing tenant boundaries, one tenant may see another tenant’s data. A vulnerable query might look like a Scan or Query on a GSI without a filter for tenantId = :currentTenant. Because DynamoDB does not enforce row-level permissions, the application must enforce it explicitly in the service or policy layer. Without this, the unauthenticated attack surface tested by middleBrick may reveal endpoints where an authenticated context is assumed but not enforced, leading to data exposure across tenants.

Another common pattern is using DynamoDB’s conditional writes or updates with dynamic key expressions derived from user input. If the condition omits ownership checks, an attacker might update or delete records they should not touch. For example, an update that uses a key built from user input without verifying that the record’s PK matches the authenticated user’s key enables privilege escalation via BFLA. middleBrick’s checks for Property Authorization and BFLA/Privilege Escalation are designed to surface such misconfigurations by comparing spec definitions with runtime behavior, ensuring that every request enforces identity-based constraints.

To align with compliance frameworks like OWASP API Top 10 and SOC2, you should treat every user-supplied identifier as untrusted. Validate identifiers against the authenticated subject, enforce tenant or ownership filters on every DynamoDB request, and avoid exposing raw DynamoDB keys to the client. middleBrick’s unauthenticated scan can highlight endpoints where these controls are missing, giving you prioritized findings with remediation guidance to tighten access control in the Strapi-DynamoDB stack.

Remediation centers on ensuring that every DynamoDB operation in Strapi includes explicit ownership or tenant checks and uses parameterized queries to avoid injection or IDOR. Instead of relying on client-supplied IDs alone, derive the partition key from the authenticated user’s identity and validate that the requested record matches that key.

For a findOne operation, first resolve the authenticated user ID from the request context, then construct the DynamoDB key within your Strapi service. Here is a concrete example using the AWS SDK for JavaScript in a Strapi service file:

const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const ddb = new DynamoDBClient({ region: 'us-east-1' });

module.exports = {
  async getProductById(userId, productId) {
    const params = {
      TableName: process.env.DYNAMODB_TABLE,
      Key: {
        PK: { S: `USER#${userId}` },
        SK: { S: `PRODUCT#${productId}` }
      }
    };
    const command = new GetItemCommand(params);
    const response = await ddb.send(command);
    if (!response.Item) {
      return null;
    }
    return {
      id: response.Item.SK.S.split('#')[1],
      name: response.Item.name.S,
      status: response.Item.status.S
    };
  }
};

This approach guarantees that users can only retrieve items where the partition key matches their own identity. To extend this pattern to list or scan operations, always include a filter on the owner attribute and use DynamoDB’s Query with a KeyConditionExpression that includes the user ID as the partition key value.

For updates and deletes, apply the same ownership verification. Here is an example of a delete operation in Strapi that ensures the authenticated user matches the record’s owner:

const { DynamoDBClient, DeleteItemCommand } = require('@aws-sdk/client-dynamodb');
const ddb = new DynamoDBClient({ region: 'us-east-1' });

module.exports = {
  async deleteProduct(userId, productId) {
    const params = {
      TableName: process.env.DYNAMODB_TABLE,
      Key: {
        PK: { S: `USER#${userId}` },
        SK: { S: `PRODUCT#${productId}` }
      }
    };
    const command = new DeleteItemCommand(params);
    const response = await ddb.send(command);
    return response;
  }
};

When using GSIs for querying, enforce tenant or user filters on the client side after the query returns results, or design your key schema so that tenant ID is part of the partition key. For example, if you query a GSI on status, include a filter for tenantId = :tenant and ensure :tenant is bound to the authenticated user’s tenant ID. This prevents cross-tenant reads that would otherwise be allowed by DynamoDB’s permissiveness.

In Strapi, you can integrate these checks into policies so that every controller action validates ownership before invoking the service layer. By combining runtime validation with DynamoDB’s conditional expressions, you reduce the risk of BOLA, IDOR, and BFLA. middleBrick’s scans can then verify that your endpoints align with these patterns, providing findings mapped to specific frameworks and prioritized remediation guidance.