Missing Tls in Express with Dynamodb

When an Express service communicates with DynamoDB without TLS, traffic between the application and the database can be observed or altered on the network. This specific combination becomes high risk when the application runs in environments where network segmentation is weak, such as shared hosting, container orchestration with misconfigured pod networks, or on-premise setups with passive monitoring. Without TLS, credentials used to sign requests, table names, and item attributes may be exposed, enabling credential theft or request tampering.

An attacker who can observe or inject packets may capture AWS access keys embedded in SDK clients or IAM role credentials assigned to the host, leading to privilege escalation across AWS services. DynamoDB streams or DynamoDB Accelerator (DAX) endpoints also rely on secure transport; skipping TLS exposes these additional surfaces. Insecure HTTP calls may be downgraded or intercepted, violating the principle of defense in depth and expanding the impact of insecure defaults. This pattern is commonly flagged in scans focused on Data Exposure and Encryption because data in transit is not protected.

For example, an Express route that creates a DynamoDB client without enforcing HTTPS can inadvertently send sensitive information in cleartext. Even when the AWS SDK defaults to HTTPS, runtime misconfiguration or custom HTTP agents may override this behavior. MiddleBrick detects such gaps by correlating unauthenticated endpoint behavior with spec analysis and active checks, highlighting missing transport protections in findings related to Encryption and Data Exposure.

Ensure all DynamoDB clients enforce HTTPS and validate server certificates. In Node.js, prefer the AWS SDK for JavaScript v3 and configure the client with explicit HTTPS agent settings. Avoid disabling SSL verification or using custom transports that bypass TLS.

const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");
const https = require("https");

const client = new DynamoDBClient({
  region: "us-east-1",
  requestHandler: {
    httpsAgent: new https.Agent({
      rejectUnauthorized: true,
    }),
  },
});

exports.handler = async (event) => {
  const params = {
    TableName: process.env.DYNAMODB_TABLE,
    Key: { id: { S: event.id } },
  };
  const command = new GetItemCommand(params);
  const response = await client.send(command);
  return {
    statusCode: 200,
    body: JSON.stringify(response.Item),
  };
};

When using the legacy AWS SDK for JavaScript (v2), enforce HTTPS by setting the sslEnabled option and avoid overriding the agent with insecure defaults:

const AWS = require("aws-sdk");

AWS.config.update({
  region: "us-west-2",
  sslEnabled: true,
});

// Explicitly disable insecure protocols
AWS.config.httpOptions = {
  agent: new (require("https").Agent)({
    rejectUnauthorized: true,
  }),
};

const docClient = new AWS.DynamoDB.DocumentClient();

exports.getItem = async (id) => {
  const params = {
    TableName: process.env.DYNAMODB_TABLE,
    Key: { id },
  };
  const data = await docClient.get(params).promise();
  return data.Item;
};

In Express, avoid passing custom http agents to the AWS SDK and never disable certificate validation. If you must use a proxy, ensure it terminates TLS with valid certificates and does not introduce weak ciphers. MiddleBrick’s CLI can validate these configurations by scanning endpoints and comparing effective runtime settings against best practices for Encryption and Data Exposure.

Finally, rotate credentials regularly, apply least-privilege IAM policies, and monitor for unexpected usage. The Pro plan’s continuous monitoring can alert you when changes to API endpoints or configurations might weaken TLS enforcement, helping maintain secure communication with DynamoDB over time.