Excessive Data Exposure in Dynamodb

Excessive data exposure occurs when an API returns more information than necessary for the intended operation. In DynamoDB‑backed services this often shows up as a Scan or Query that omits a FilterExpression or ProjectionExpression, causing the service to stream every attribute of every item back to the caller.

• Unfiltered Scan: A Scan without a FilterExpression returns all items in the table, potentially exposing PII, password hashes, or internal identifiers.
• Unprojected Attributes: Even when the number of items is limited, returning all attributes (e.g., omitting ProjectionExpression) can leak fields such as email, phoneNumber, or secretKey that the client does not need.
• Pagination Mis‑configuration: Using a high Limit value or ignoring LastEvaluatedKey can cause a single request to pull large chunks of data, amplifying exposure.

Example of vulnerable Node.js code using the AWS SDK:

const AWS = require('aws-sdk');
const docClient = new AWS.DynamoDB.DocumentClient();

async function getAllUsers() {
  const params = {
    TableName: 'Users'
    // No FilterExpression, no ProjectionExpression
  };
  try {
    const data = await docClient.scan(params).promise();
    return data.Items; // returns every attribute of every user
  } catch (err) {
    console.error('Error', err);
  }
}

This pattern maps to OWASP API Security Top 10 2019 – API3: Excessive Data Exposure, and has been observed in real‑world incidents such as CVE‑2020‑13942 (misconfigured DynamoDB Scan leading to customer data leak).

middleBrick performs an unauthenticated black‑box scan of the API endpoint. When it encounters a route that invokes a DynamoDB operation, it examines the HTTP response for:

• Fields that are not declared in the associated OpenAPI/Swagger schema (if provided).
• Attribute names that match common sensitive patterns (e.g., ssn, password, api_key).
• Response sizes that exceed what would be expected from a properly filtered query.

If such discrepancies are found, middleBrick creates a Data Exposure finding with a severity rating (typically Medium or High) and includes remediation guidance in the report.

Example CLI usage:

middlebrick scan https://api.example.com/users

The output (JSON) might contain a finding like:

{
  "category": "Data Exposure",
  "severity": "high",
  "description": "Response includes unexpected attributes: ssn, internalId",
  "remediation": "Add a ProjectionExpression to limit returned attributes and a FilterExpression to restrict items."
}

Because middleBrick requires no agents, no credentials, and only the public URL, it can be run against staging or production endpoints as part of a CI pipeline (GitHub Action) or locally via the CLI.

Fixing excessive data exposure in DynamoDB relies on using the service’s native request shaping features:

• ProjectionExpression: Specify only the attributes the client needs.
• FilterExpression: Limit the set of items returned to those that satisfy business logic.
• Pagination: Honor LastEvaluatedKey and use a reasonable Limit to avoid pulling large data chunks in a single call.
• IAM Policies with Condition Keys: Restrict which attributes a role may read using dynamodb:Attributes condition keys (e.g., deny ssn).

Corrected version of the earlier example:

const AWS = require('aws-sdk');
const docClient = new AWS.DynamoDB.DocumentClient();

async function getActiveUsers() {
  const params = {
    TableName: 'Users',
    FilterExpression: '#status = :status',
    ProjectionExpression: '#id, #name, email, #createdAt',
    ExpressionAttributeNames: {
      '#id': 'userId',
      '#name': 'name',
      '#createdAt': 'createdAt',
      '#status': 'status'
    },
    ExpressionAttributeValues: {
      ':status': 'active'
    },
    Limit: 50 // reasonable page size
  };
  try {
    const data = await docClient.scan(params).promise();
    return data.Items; // now returns only needed attributes
  } catch (err) {
    console.error('Error', err);
  }
}

Additional best practices:

• Enable encryption at rest (AWS managed or customer‑managed CMK) to protect data if exfiltration occurs.
• Use VPC endpoints for DynamoDB to keep traffic off the public internet.
• Regularly review IAM policies to ensure least‑privilege access to specific tables and attributes.

After applying these changes, a rescan with middleBrick will show the Data Exposure finding resolved (or downgraded to Low if only non‑sensitive fields remain).