Container Escape in Express with Dynamodb

A container escape in an Express service that uses DynamoDB typically occurs when an attacker who has compromised the application or its runtime can leverage the application’s permissions and the container’s environment to interact with the host or other containers. In this stack, DynamoDB itself does not cause the escape, but the way the Express app uses AWS credentials and container-level resources can amplify impact if the application is over-permissioned or if host paths are mounted into the container.

Express applications often run in containers with IAM credentials supplied through instance metadata, ECS task roles, or Kubernetes secrets mounted as files. If the Express app has write access to DynamoDB tables and the container mounts host paths (for example, the Docker socket /var/run/docker.sock or the host’s filesystem), an attacker who can trigger arbitrary code execution in the app may leverage those mounted resources to escalate to the host. For example, if the app deserializes untrusted input and the runtime has permissions to call DynamoDB operations like PutItem or UpdateItem, an attacker might chain a server-side request forgery (SSRF) or command injection to abuse the container’s elevated capabilities.

The DynamoDB API calls in Express typically use the AWS SDK for JavaScript. If the SDK is configured with broad IAM permissions (e.g., dynamodb:*) and the container runs with a task role that grants such permissions, an attacker who achieves code execution could issue destructive or reconnaissance DynamoDB actions. Additionally, if the Express app exposes administrative endpoints that invoke DynamoDB operations without strict input validation, an attacker might use malformed keys or table names to probe the service. The container environment can further expose metadata endpoints or shared memory that may aid lateral movement.

Consider a scenario where an Express route accepts a table name and key from user input and calls getItem. Without strict schema checks and least-privilege IAM, an attacker might attempt to reference sensitive tables or invoke low-level DynamoDB operations that expose data beyond the intended scope. If the container is misconfigured and shares the network namespace with other containers or mounts sensitive host paths, the combined effect of a vulnerable Express app and a permissive DynamoDB policy can facilitate actions that escape the container boundary, such as reading host files via a malicious SDK plugin or abusing AWS credentials to access other services.

To mitigate this specific combination, apply the principle of least privilege to the IAM role used by the Express application, ensuring it only has the DynamoDB permissions necessary for its function. Avoid mounting sensitive host paths into the container, and restrict network access to metadata services where possible. Validate and sanitize all inputs to DynamoDB calls, and use condition expressions to prevent unintended operations. Monitor for anomalous DynamoDB activity from your containerized Express service as part of continuous security practices.

Remediation focuses on tightening IAM permissions, validating inputs, and ensuring the Express app does not expose DynamoDB operations to untrusted input. Below are concrete code examples for secure Express usage with DynamoDB.

• Use least-privilege IAM policies for the DynamoDB calls your app needs. For example, if the app only needs to read items from a specific table, grant dynamodb:GetItem and dynamodb:Query on that table ARN only.
• Validate and sanitize all inputs before using them in DynamoDB requests. Do not trust user-supplied table names or key schemas; enforce strict allowlists.
• Use condition expressions to ensure updates only proceed when expected conditions hold, preventing accidental overwrites or injection-style manipulation.

Secure Express route example with DynamoDB DocumentClient:

const { DynamoDBDocumentClient, GetCommand } = require("@aws-sdk/lib-dynamodb");
const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");
const express = require("express");

const client = new DynamoDBClient({ region: "us-east-1" });
const ddbDocClient = DynamoDBDocumentClient.from(client);

const app = express();
app.use(express.json());

// Whitelist of allowed tables to prevent table injection
const ALLOWED_TABLES = new Set(["users", "products"]);

app.get("/items/:table", async (req, res) => {
  const { table } = req.params;
  const { id } = req.query;

  if (!ALLOWED_TABLES.has(table)) {
    return res.status(400).json({ error: "Invalid table name" });
  }
  if (!id || typeof id !== "string") {
    return res.status(400).json({ error: "Invalid id" });
  }

  const command = new GetCommand({
    TableName: table,
    Key: { id: { S: id } },
  });

  try {
    const { Item } = await ddbDocClient.send(command);
    if (!Item) {
      return res.status(404).json({ error: "Not found" });
    }
    // Convert DynamoDB attribute values to plain JavaScript values
    const plainItem = DynamoDBDocumentClient.unmarshall(Item);
    res.json(plainItem);
  } 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 example, the table name is validated against an allowlist, the key is type-checked, and the SDK is configured with a specific region. This reduces the risk of unauthorized table access and injection-style attacks that could be chained with container or host interactions.

For continuous protection, use the middleBrick CLI to scan your Express endpoints and review DynamoDB-related findings. The CLI scans from terminal with middlebrick scan <url> and can be integrated into scripts to enforce security gates. Teams using the Pro plan can enable continuous monitoring to detect regressions in API security posture over time, and the GitHub Action adds API security checks to your CI/CD pipeline, failing builds if risk scores drop below your chosen threshold.