Path Traversal in Loopback with Dynamodb

Path Traversal occurs when user-controlled input is used to access files or resources outside the intended directory. In a Loopback application that uses Dynamodb as a persistence layer, the risk typically arises not from Dynamodb itself (which is a managed key-value store without a traditional filesystem), but from how application code builds keys or references based on unvalidated input. For example, if an endpoint accepts a userId or fileName parameter and uses it directly to construct a DynamoDB key (partition key or sort key), an attacker may attempt directory traversal sequences such as ../../../secrets to manipulate logical key paths or access unintended data partitions.

Consider a Loopback model configured to store user documents in DynamoDB with a composite key like userId#documentId. If the API does not sanitize documentId, an attacker could supply a value such as ../../../admin/profile. The application might naively concatenate this into a key string and pass it to a DynamoDB GetItem or Query operation. While DynamoDB will treat the literal string as a key, the effective access pattern may bypass intended tenant isolation or expose sensitive items that should be logically separated. This breaks the application’s logical boundaries, leading to unauthorized data access, a common manifestation of Insecure Direct Object References (IDOR) or Broken Level of Access Control (BOLA).

Another scenario involves metadata or configuration stored in DynamoDB that references logical resource paths. If user input is used to look up these references without validation, traversal sequences can point to unexpected configuration entries or administrative records. Because DynamoDB does not enforce a directory hierarchy, the onus is on the application to enforce strict validation and canonicalization of keys before using them in operations. Without this, the API surface includes endpoints that may appear to retrieve user-specific data but can, through crafted traversal inputs, reach across partitions that the caller should not access.

middleBrick can detect such issues by analyzing the unauthenticated attack surface of a Loopback + Dynamodb API. During an automated scan, it tests input vectors that include traversal patterns and examines whether the API responds with data leaks or inconsistent authorization behavior. Findings often highlight missing validation on key parameters, missing tenant-context checks, and insufficient boundary enforcement around user-supplied identifiers. These findings map to the OWASP API Top 10 (e.g., Broken Object Level Authorization) and may also relate to compliance frameworks such as SOC2 and GDPR.

Remediation focuses on strict validation, canonicalization, and scoping of keys used with DynamoDB. Never trust user input to construct keys directly. Instead, enforce allowlists, normalize paths, and enforce tenant or ownership context before performing any DynamoDB operation.

Validation and canonicalization example

Ensure that identifiers are stripped of traversal sequences and restricted to safe characters before being used in DynamoDB keys.

const path = require('path');

function sanitizeKey(input) {
  // Remove path traversal attempts and normalize
  const normalized = path.normalize(input).replace(/^(\.\.[\/\\])+/, '');
  // Allow only alphanumeric, underscore, and hyphen
  if (!/^[a-zA-Z0-9_-]+$/.test(normalized)) {
    throw new Error('Invalid key: contains disallowed characters');
  }
  return normalized;
}

// Usage in a Loopback repository method
async findDocument(userId, documentId) {
  const safeUserId = sanitizeKey(userId);
  const safeDocId = sanitizeKey(documentId);
  const key = { pk: `USER#${safeUserId}`, sk: `DOCUMENT#${safeDocId}` };
  const result = await this.dynamodb.get(key).promise();
  return result.Item;
}

Enforcing tenant context

Always include tenant or owner information in the key construction and verify it matches the authenticated context before issuing a DynamoDB request.

async getTenantDocument(ctx, documentId) {
  const safeDocId = sanitizeKey(documentId);
  const tenantId = ctx.req.user.tenantId; // enforced by authentication middleware
  const key = { pk: `TENANT#${tenantId}`, sk: `DOCUMENT#${safeDocId}` };
  const result = await this.dynamodb.get(key).promise();
  if (!result.Item || result.Item.tenantId !== tenantId) {
    throw new Error('Access denied or item not found');
  }
  return result.Item;
}

Using DynamoDB ConditionExpression to enforce ownership

Even after key construction, use condition expressions to ensure the item belongs to the expected tenant, adding a safety layer against programming errors.

async updateDocument(userId, documentId, update) {
  const safeUserId = sanitizeKey(userId);
  const safeDocId = sanitizeKey(documentId);
  const key = { pk: `USER#${safeUserId}`, sk: `DOCUMENT#${safeDocId}` };
  await this.dynamodb.update({
    Key: key,
    UpdateExpression: 'set #data = :data',
    ConditionExpression: 'pk = :pk and sk = :sk',
    ExpressionAttributeNames: { '#data': 'data' },
    ExpressionAttributeValues: {
      ':data': update.data,
      ':pk': `USER#${safeUserId}`,
      ':sk': `DOCUMENT#${safeDocId}`
    }
  }).promise();
  return this.findDocument(userId, documentId);
}

For broader API security coverage across such patterns, middleBrick can be used via the CLI (middlebrick scan <url>), GitHub Action, or MCP Server in your IDE to continuously assess endpoints that interact with DynamoDB. The Pro plan adds continuous monitoring and CI/CD integration, helping teams catch regressions before deployment.