HIGH missing tlsdynamodb

Missing Tls in Dynamodb

How Missing Tls Manifests in Dynamodb

Missing TLS in DynamoDB contexts creates several unique attack vectors that differ from standard HTTP API vulnerabilities. When DynamoDB clients connect without TLS, the most common manifestation occurs through the AWS SDK's default configuration, which may fall back to HTTP endpoints in certain network configurations or when credentials are misconfigured.

The primary attack pattern involves credential interception during DynamoDB API calls. Without TLS, AWS access keys travel in plaintext across the network, allowing attackers on the same network segment to capture credentials and gain full database access. This is particularly dangerous in multi-tenant environments where DynamoDB endpoints might be accessible through internal networks without proper segmentation.

Another critical manifestation occurs during DynamoDB stream processing. Applications that consume DynamoDB streams without TLS can expose sensitive data modifications to network observers. Attackers can monitor these streams to reconstruct business logic, identify high-value records, or track user behavior patterns based on database changes.

DynamoDB's Global Tables feature introduces additional TLS risks. When configuring cross-region replication without proper TLS enforcement, data synchronization between regions can expose sensitive data across geographical boundaries. This creates compliance violations for organizations subject to data residency requirements.

The AWS SDK for JavaScript provides a concrete example of how missing TLS manifests:

// Vulnerable: No TLS enforcement
const dynamodb = new AWS.DynamoDB({
region: 'us-east-1',

This configuration explicitly disables TLS, making all DynamoDB operations susceptible to man-in-the-middle attacks. The SDK's default behavior attempts to use HTTPS, but explicit HTTP endpoints override this security.

Lambda functions accessing DynamoDB present another manifestation vector. Cold starts in Lambda can sometimes establish connections through cached HTTP endpoints if the function's network configuration allows it, creating intermittent TLS failures that are difficult to detect in production.

Dynamodb-Specific Detection

Detecting missing TLS in DynamoDB environments requires examining both configuration and runtime behavior. The AWS SDK configuration files often contain the first indicators of potential TLS issues. Look for endpoint configurations that specify HTTP rather than HTTPS protocols.

Network-level detection involves monitoring DynamoDB traffic patterns. Tools like Wireshark can identify unencrypted DynamoDB API calls by examining the protocol headers. DynamoDB's API uses specific HTTP methods and headers that make unencrypted traffic identifiable even without deep packet inspection.

middleBrick's DynamoDB-specific scanning examines several critical areas. The scanner tests DynamoDB endpoints by attempting connections with various configurations to identify endpoints that accept unencrypted connections. It specifically checks for:

- DynamoDB endpoint configurations that allow HTTP connections
- Lambda function IAM roles that might permit unencrypted DynamoDB access
- API Gateway integrations with DynamoDB that lack TLS enforcement
- Application code that explicitly sets HTTP endpoints in AWS SDK configurations

The scanner also examines DynamoDB stream configurations, testing whether stream consumers can be accessed without TLS. This is particularly important for applications using DynamoDB streams for real-time processing or change data capture.

Configuration analysis includes examining CloudFormation templates, Terraform configurations, and AWS CloudFormation stacks for DynamoDB resources. The scanner looks for:

# Vulnerable configuration - no TLS enforcement
resource "aws_dynamodb_table" "example" {
name = "example-table"
billing_mode = "PROVISIONED"
write_capacity = 20
# Missing TLS configuration

middleBrick's LLM/AI security module also checks for DynamoDB configurations in AI/ML applications, as these often handle sensitive training data that requires encryption in transit.

Runtime detection involves monitoring DynamoDB API calls through CloudTrail logs, looking for any API operations that might indicate unencrypted connections or misconfigured endpoints.

Dynamodb-Specific Remediation

Remediating missing TLS in DynamoDB requires a multi-layered approach that addresses both configuration and code-level issues. The foundation is ensuring all DynamoDB client configurations explicitly require TLS.

For AWS SDK implementations, the remediation starts with proper endpoint configuration:

// Secure configuration with TLS enforcement
const dynamodb = new AWS.DynamoDB({
region: 'us-east-1',

This configuration ensures that any attempt to use HTTP endpoints will fail, preventing accidental exposure of credentials and data.

Lambda functions require special attention. The remediation involves adding VPC configurations and security group rules that only allow HTTPS traffic to DynamoDB endpoints:

// Secure Lambda DynamoDB access
export const handler = async (event: any) => {
const dynamodb = new AWS.DynamoDB({
region: process.env.AWS_REGION,

For infrastructure-as-code configurations, remediation involves updating resource definitions to enforce TLS:

# Secure DynamoDB configuration
resource "aws_dynamodb_table" "secure_table" {
name = "secure-example-table"
billing_mode = "PROVISIONED"
read_capacity = 20
write_capacity = 20

point_in_time_recovery {

# TLS is enforced by default for AWS services
server_side_encryption {

Application-level remediation includes implementing certificate pinning for DynamoDB connections in high-security environments:

import boto3
from botocore.client import Config

# Secure DynamoDB client with TLS verification
secure_config = Config(
signature_version='v4',

dynamodb = boto3.resource('dynamodb',

For applications using DynamoDB streams, remediation requires implementing TLS for all stream consumers and ensuring that stream endpoints are only accessible through secure channels.

middleBrick's CLI tool can verify these remediations by scanning your deployed APIs:

# Scan DynamoDB API endpoints for TLS compliance
middlebrick scan https://dynamodb.us-east-1.amazonaws.com --category TLS

The GitHub Action integration allows automated TLS verification in CI/CD pipelines:

- name: DynamoDB TLS Security Scan
uses: middleBrick/middlebrick@v1
with:
target: https://dynamodb.us-east-1.amazonaws.com
category: TLS
fail-on-severity: high

These remediations ensure that DynamoDB communications remain encrypted, protecting both credentials and sensitive data from network-based attacks.

Related CWEs: encryption

CWE IDNameSeverity
CWE-319Cleartext Transmission of Sensitive Information HIGH
CWE-295Improper Certificate Validation HIGH
CWE-326Inadequate Encryption Strength HIGH
CWE-327Use of a Broken or Risky Cryptographic Algorithm HIGH
CWE-328Use of Weak Hash HIGH
CWE-330Use of Insufficiently Random Values HIGH
CWE-338Use of Cryptographically Weak PRNG MEDIUM
CWE-693Protection Mechanism Failure MEDIUM
CWE-757Selection of Less-Secure Algorithm During Negotiation HIGH
CWE-261Weak Encoding for Password HIGH

Frequently Asked Questions

Why does DynamoDB sometimes appear to work without TLS in development environments?
DynamoDB SDK clients may fall back to HTTP endpoints when HTTPS connections fail due to network configurations, proxy settings, or explicit endpoint specifications. This behavior is particularly common in development environments with restrictive network policies or when using local DynamoDB instances. The SDK's default behavior attempts HTTPS first, but explicit HTTP configurations or network failures can trigger unencrypted connections, exposing credentials and data to interception.
How does middleBrick detect missing TLS in DynamoDB configurations?
middleBrick performs black-box scanning of DynamoDB endpoints by attempting connections with various configurations to identify endpoints that accept unencrypted connections. The scanner examines AWS SDK configurations, CloudFormation templates, and runtime behavior to detect HTTP endpoints, missing TLS enforcement, and vulnerable Lambda function configurations. It specifically tests for DynamoDB stream consumers that might be accessible without TLS and provides detailed findings with severity levels and remediation guidance.