Broken Access Control in Restify with Dynamodb

Broken Access Control in a Restify service that uses DynamoDB often arises from conflating HTTP identity/authorization handling with how DynamoDB evaluates requests. In a typical Restify plugin or handler, an incoming request’s user identity is mapped to an IAM principal (for example, via an API key, JWT, or Cognito authorizer). If the handler then passes a userId from the request (e.g., from a URL parameter or a client-supplied JSON body) directly to DynamoDB operations, it can inadvertently allow one user to read or modify another user’s data.

A concrete pattern: a GET endpoint like /users/{userId}/profile in Restify retrieves the path parameter userId and uses it as the KeyExpression in a DynamoDB GetItem or Query. If the service does not verify that the authenticated user matches the supplied userId, an attacker can change the parameter to access other profiles. This is a BOLA/IDOR issue that manifests through DynamoDB because the database enforces only the permissions of the IAM role used by the service, not per-user data boundaries.

DynamoDB itself does not understand application-level user ownership; it only evaluates IAM policies and condition expressions. When a Restify handler supplies an IAM role with broad DynamoDB permissions (e.g., dynamodb:GetItem on a table), and also supplies a user-controlled key, the service acts as a proxy that can be tricked into crossing tenant boundaries. Additionally, if the handler builds a DynamoDB query using string concatenation or unsanitized input to construct filter expressions, an attacker may attempt injection to affect which items are returned or to cause unexpected traversal across partitions.

Because Restify is a Node.js server framework, typical middleware flow is: authenticate request (e.g., via JWT), load user context, then invoke a service function that calls DynamoDB. If the authorization middleware does not enforce that the resource being accessed belongs to the authenticated subject, the DynamoDB call executes with the service’s IAM permissions, returning data the user should not see or allowing writes to another user’s item. This is why mapping HTTP-level authorization to DynamoDB expression attribute values is critical: you must ensure the key condition includes the authenticated user’s ID and that IAM policies restrict the role to least privilege on the table (for example, granting access only to partition keys derived from the user’s sub).

Real-world analogues include AWS access logs showing GetItem/Query requests where the partition key differs from the authenticated caller’s ID, or CloudTrail records where a role with dynamodb:Query is called with a KeyConditionExpression controlled by the caller. OWASP API Top 10 A01:2023 (Broken Object Level Authorization) maps directly to this pattern, and frameworks like Restify require explicit checks to prevent horizontal privilege escalation across DynamoDB items.

To fix Broken Access Control when using DynamoDB in Restify, enforce user-to-resource mapping at the handler level and use DynamoDB condition expressions to guarantee data isolation. Below are two focused examples for a profile endpoint and a safe query pattern.

Example 1: Safe GET profile with authenticated user mapping

Ensure the authenticated user’s ID (e.g., from a JWT) is used as the partition key and that the incoming userId matches. Do not rely on client-supplied identifiers alone.

const restify = require('restify');
const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');

const server = restify.createServer();
const db = new DynamoDBClient({ region: 'us-east-1' });

server.get('/profiles/me', async (req, res, next) => {
  // Assume req.user is set by an auth plugin (e.g., JWT) with a stable user ID
  const authenticatedUserId = req.user.sub; // e.g., 'user-123'

  const command = new GetItemCommand({
    TableName: process.env.PROFILES_TABLE,
    Key: {
      userId: { S: authenticatedUserId }
    },
    // Optional: ProjectionExpression to limit returned attributes
  });

  const response = await db.send(command);
  if (!response.Item) {
    return res.send(404, { error: 'not_found' });
  }
  res.send(200, response.Item);
  next();
});

server.listen(8080, () => console.log('Listening'));

Example 2: Query with user-scoped filter using ExpressionAttributeValues

When querying a user’s items, always include the authenticated user ID in the key condition or filter and use ExpressionAttributeValues instead of string interpolation to avoid injection and ensure correct scoping.

const restify = require('restify');
const { DynamoDBClient, QueryCommand } = require('@aws-sdk/client-dynamodb');

const server = restify.createServer();
const db = new DynamoDBClient({ region: 'us-east-1' });

server.get('/users/:userId/items', async (req, res, next) => {
  const authenticatedUserId = req.user.sub;
  const requestedUserId = req.params.userId;

  if (authenticatedUserId !== requestedUserId) {
    return res.send(403, { error: 'access_denied' });
  }

  const command = new QueryCommand({
    TableName: process.env.ITEMS_TABLE,
    KeyConditionExpression: 'ownerId = :owner',
    ExpressionAttributeValues: {
      ':owner': { S: requestedUserId }
    },
    // Limit results to prevent excessive data exposure
    Limit: 50
  });

  const response = await db.send(command);
  res.send(200, response.Items);
  next();
});

Additional remediation practices include: - Use IAM policies with dynamodb:Query scoped to a partition key prefix derived from the user (if using composite keys), rather than full table access. - Validate and normalize IDs (e.g., UUIDs) before using them in DynamoDB keys to avoid path traversal or unexpected key patterns. - Employ middleware that attaches the authenticated subject to req.user and ensure every DynamoDB call references that subject rather than client-controlled parameters. - When using indexes, ensure the partition key on the index also incorporates the user context to maintain isolation.