Excessive Data Exposure in Express with Dynamodb

Excessive Data Exposure occurs when an API returns more data than the client needs, often including sensitive fields that should remain restricted. In an Express service that uses DynamoDB as the persistence layer, this typically arises from directly passing DynamoDB query results to the response without explicit field filtering. Because DynamoDB stores items as flexible attribute maps, it is easy to accidentally serialize and return attributes such as internal identifiers, administrative flags, or personal information that were intended for server-side use only.

For example, a GET /users/:userId endpoint might perform a GetItem against a DynamoDB table and return the full item. If the table stores attributes like passwordHash, apiKey, or isAdmin alongside profile fields, the response will include them unless the application explicitly omits them. This becomes more pronounced when using the Document Client, which simplifies attribute handling but does not enforce output constraints. An attacker who can influence path parameters or leverage broken access control to escalate privileges may then harvest credentials or sensitive metadata from these oversized responses.

The interaction with DynamoDB also means that developers may rely on sparse attribute structures, inadvertently leaving test or debug attributes in production items. Because the scan and query operations in DynamoDB can return all attributes for matching items, there is a direct path from permissive query design to data exposure. When combined with misconfigured CORS or missing JSON schema validation on the Express side, the risk of leaking internal fields increases further.

To prevent Excessive Data Exposure, Express routes that interact with DynamoDB should explicitly construct response payloads that include only the intended fields. This involves avoiding automatic serialization of raw DynamoDB responses and instead mapping items to lean data transfer objects.

Below are concrete, syntactically correct examples for an Express route using the AWS SDK for JavaScript v3 with DynamoDB.

import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
import { unmarshall } from "@aws-sdk/util-dynamodb";
import express from "express";

const client = new DynamoDBClient({ region: "us-east-1" });
const app = express();

app.get("/users/:userId", async (req, res) => {
  const { userId } = req.params;

  const command = new GetItemCommand({
    TableName: process.env.USERS_TABLE,
    Key: {
      userId: { S: userId },
    },
  });

  try {
    const result = await client.send(command);
    if (!result.Item) {
      return res.status(404).json({ error: "User not found" });
    }

    // Explicitly select only safe attributes; omit passwordHash, apiKey, isAdmin, etc.
    const user = unmarshall(result.Item);
    const safeUser = {
      userId: user.userId,
      email: user.email,
      name: user.name,
      avatarUrl: user.avatarUrl,
      createdAt: user.createdAt,
    };

    res.json(safeUser);
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: "Internal server error" });
  }
});

app.listen(3000, () => {
  console.log("Server running on port 3000");
});

In this pattern, the unmarshalled DynamoDB item is transformed into a controlled object. This ensures that no hidden or sensitive attributes are present in the HTTP response, regardless of how the DynamoDB item is stored. For list endpoints, apply the same selective mapping within an array transformation to maintain consistency.

Additionally, consider validating incoming query parameters against a strict schema and enforcing field-level read permissions so that even if a client requests more detail, the server does not provide it. These practices align with the Excessive Data Exposure checks in middleBrick, which correlate findings to the OWASP API Top 10 and provide prioritized remediation guidance.