Cryptographic Failures in Express with Dynamodb

When an Express application stores or retrieves data from Amazon DynamoDB, cryptographic failures often arise from inconsistent or incomplete protection of data at rest and in transit. DynamoDB supports encryption at rest using AWS-owned keys or customer managed keys, but the serverless database does not automatically enforce encryption of field-level values before they are sent from the application. If Express routes pass sensitive values such as authentication tokens, personal identifiable information (PII), or secrets directly into DynamoDB put or update requests without explicit encryption, those values may be exposed in application logs, CloudTrail events, or through compromised IAM credentials.

Additionally, client-side cryptographic operations are frequently mishandled in Express codebases. For example, developers may encrypt data in one route using a static key and then attempt to decrypt it in another route without securely managing key rotation, initialization vectors, or authentication tags. This can lead to weak cryptography choices, such as using Electronic Codebook (ECB) mode or predictable IVs, which make data susceptible to pattern analysis. MiddleBrick’s cryptographic checks specifically flag scenarios where sensitive fields are written to DynamoDB without authenticated encryption or where responses from LLM endpoints (if integrated) inadvertently expose keys or tokens, aligning with findings from the OWASP API Top 10 and data exposure categories.

Another common failure path involves the transmission layer. Express apps must ensure that all requests to DynamoDB use HTTPS and that the AWS SDK is configured to enforce TLS. Misconfigured HTTP agents or outdated SDK defaults can inadvertently allow cleartext communication, exposing credentialed requests. Since DynamoDB does not perform application-layer validation of payload structure, malformed or unencrypted JSON can be accepted, increasing the risk of insecure deserialization or injection-style issues when data is later decrypted and used. The LLM/AI Security checks in middleBrick also test for system prompt leakage and output scanning for API keys, which can occur if sensitive data is mistakenly echoed in logs or error messages tied to DynamoDB operations.

To remediate cryptographic failures, implement deterministic encryption for searchable fields and authenticated encryption for sensitive values before they reach DynamoDB. Use the AWS SDK for JavaScript with strict TLS settings and rotate data keys via AWS KMS. Below are concrete Express route examples that demonstrate secure handling.

const express = require('express');
const { DynamoDBClient, PutItemCommand, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const { KMSClient, EncryptCommand, DecryptCommand } = require('@aws-sdk/client-kms');
const app = express();
app.use(express.json());

const region = process.env.AWS_REGION || 'us-east-1';
const client = new DynamoDBClient({ region });
const kms = new KMSClient({ region });
const keyId = process.env.KMS_KEY_ID;

async function encryptData(plaintext) {
  const cmd = new EncryptCommand({
    KeyId: keyId,
    Plaintext: Buffer.from(plaintext)
  });
  const { CiphertextBlob } = await kms.send(cmd);
  return CiphertextBlob.toString('base64');
}

async function decryptData(ciphertextBlobBase64) {
  const cmd = new DecryptCommand({
    CiphertextBlob: Buffer.from(ciphertextBlobBase64, 'base64')
  });
  const { Plaintext } = await kms.send(cmd);
  return Plaintext.toString('utf8');
}

app.post('/users', async (req, res) => {
  const { email, ssn } = req.body;
  const encryptedSSN = await encryptData(ssn);
  const params = {
    TableName: process.env.DYNAMO_TABLE,
    Item: {
      email: { S: email },
      ssn: { S: encryptedSSN }
    }
  };
  await client.send(new PutItemCommand(params));
  res.status(201).send({ message: 'User created' });
});

app.get('/users/:email', async (req, res) => {
  const { email } = req.params;
  const params = {
    TableName: process.env.DYNAMO_TABLE,
    Key: { email: { S: email } }
  };
  const { Item } = await client.send(new GetItemCommand(params));
  if (!Item) return res.status(404).send({ error: 'Not found' });
  const ssn = await decryptData(Item.ssn.S);
  res.json({ email: Item.email.S, ssn: ssn });
});

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

In this example, the Express app uses envelope encryption via AWS KMS to protect the SSN before it is written to DynamoDB. The encryption and decryption are handled explicitly in route handlers, avoiding reliance on DynamoDB server-side encryption for field-level confidentiality. Ensure that the KMS key policy restricts use to specific roles and that the Express environment enforces HTTPS for all outbound AWS SDK calls. middleBrick’s CLI can be used to scan this endpoint from the terminal with middlebrick scan <url>, while the GitHub Action can enforce a security score threshold in CI/CD to prevent regressions.

Additional remediation steps include: rotating KMS keys on a defined schedule, disabling unused IAM permissions for the Express role, and validating input to prevent injection of malformed payloads that could bypass encryption logic. For continuous monitoring, the Pro plan provides configurable scans and Slack/Teams alerts to notify maintainers when a cryptographic finding is detected. If LLM endpoints are integrated, the MCP Server allows you to scan APIs directly from your AI coding assistant to catch insecure usage patterns early.