Pii Leakage in Express with Dynamodb

PII leakage in an Express service that uses DynamoDB often occurs at the intersection of application logic, data modeling, and API exposure. When Express endpoints directly proxy user-supplied identifiers to DynamoDB queries, and those queries return items that contain personal data, the risk of exposing PII rises if responses are not explicitly filtered.

DynamoDB itself stores data as attribute-value pairs; if tables hold fields such as email, phone_number, or ssn alongside operational attributes, an endpoint that fetches an item by key can unintentionally return all attributes. Without a strict projection or a server-side filter, the full item—including PII—can be serialized into the HTTP response. A common pattern is using a path parameter like /users/:userId to retrieve a user record. If the route handler runs docClient.get({ TableName, Key: { userId } }) and returns the entire item, every attribute stored in that item is exposed.

Another vector is secondary indexes. Global and local secondary indexes can include different attributes than the base table, and queries against them can surface PII if the application consumes the index results without applying the same field-level controls. Additionally, DynamoDB Streams can feed change data into downstream consumers; if those consumers or intermediary services re-expose data without redaction, PII can leak through logging or callbacks.

Express-specific factors amplify the risk. Middleware that adds headers or logs request/response bodies might inadvertently capture PII if responses are not pruned. Inadequate error handling can also reveal stack traces or internal identifiers that, combined with data returned from DynamoDB, aid an attacker. The scan categories relevant here include Data Exposure, Input Validation, and Unsafe Consumption, which help identify whether endpoints return sensitive fields or accept unchecked input that influences which attributes are retrieved.

To illustrate a vulnerable flow: an endpoint accepts a user-supplied userId, fetches the item from DynamoDB, and returns it as JSON. If the item contains email and the endpoint does not strip it, the PII is exposed. The fix is not to store less data, but to ensure retrieval operations use explicit projection expressions, and to apply consistent field-level filtering before serialization.

Remediation centers on controlling which attributes are fetched and how they are presented. Use DynamoDB’s ProjectionExpression to retrieve only the necessary attributes, and avoid returning the full item by default. Combine this with server-side field filtering and strict schema governance to ensure PII is never unintentionally surfaced.

Example: safe retrieval with a projection expression and explicit selection of non-sensitive fields.

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

app.get('/users/:userId', async (req, res) => {
  const { userId } = req.params;
  const params = {
    TableName: process.env.USERS_TABLE,
    Key: { userId },
    // Fetch only the attributes you need; exclude PII
    ProjectionExpression: 'userId,username,createdAt,profileStatus'
  };

  try {
    const data = await docClient.get(params).promise();
    if (!data.Item) {
      return res.status(404).json({ error: 'User not found' });
    }
    res.json(data.Item);
  } catch (err) {
    console.error('DynamoDB get error:', err);
    res.status(500).json({ error: 'Internal server error' });
  }
});

For cases where you must conditionally include certain fields, use expression attribute names to avoid reserved keyword conflicts and keep the code robust.

Example: using ExpressionAttributeNames and conditional inclusion (still explicit).

const params = {
  TableName: process.env.USERS_TABLE,
  Key: { userId },
  ProjectionExpression: '#u, email, #s',
  ExpressionAttributeNames: {
    '#u': 'userId',
    '#s': 'status'
  }
};
// Note: do not include 'email' here if it is PII; this is illustrative.

If business logic requires reading more attributes for internal processing but the API must return a subset, perform filtering on the server before sending the response. Never rely on client-side omission or JavaScript removal to prevent PII leakage.

When using DynamoDB Streams, ensure consumers apply the same field-level controls and do not forward full items to downstream APIs or logs without scrubbing. For scan and query operations, prefer filtered projections over unselective reads, and validate that indexes do not inadvertently expose PII through their attribute sets.

Finally, integrate continuous scanning (e.g., via the Pro plan with monthly checks or the GitHub Action for CI/CD gates) to detect when endpoints or data models change in ways that reintroduce PII exposure. The dashboard can track security scores over time, and findings will map to relevant compliance frameworks such as GDPR and SOC2, providing prioritized remediation guidance.