Missing Tls in Django with Dynamodb

When a Django application communicates with Amazon DynamoDB without Transport Layer Security (TLS), credentials, session tokens, and potentially sensitive data can traverse the network in cleartext. This specific combination—Django as the web framework and DynamoDB as the backend datastore—becomes vulnerable because DynamoDB endpoints that do not enforce TLS can be reached over HTTP. An attacker positioned to intercept traffic (for example, on an untrusted network or via a compromised network device) can capture requests that include AWS signature headers, which may reveal access keys or IAM role information if the application uses instance profiles or temporary credentials.

In practice, this risk materializes when the AWS SDK used by Django is configured with an endpoint URL that does not start with https://, or when a misconfigured HTTP client or proxy allows downgrade attacks. Even when using the official boto3 client, if the verify parameter is set to False or a custom CA bundle is missing, TLS validation is bypassed. The Django settings that control HTTP clients (such as those used for health checks or custom management commands) may inadvertently allow insecure connections, and DynamoDB streams or DAX endpoints that are not served over TLS amplify exposure. Because DynamoDB requests often carry IAM permissions in signed headers, exposure can lead to privilege escalation if captured and replayed.

Additionally, without TLS, integrity checks are absent; an attacker could modify in-flight requests or responses, potentially causing the application to write incorrect data to DynamoDB or read unintended records. This intersects with the broader OWASP API Security Top 10 category of Security Misconfiguration, where missing encryption in transit is a common finding in scans run by tools such as middleBrick, which flags missing TLS as a high-severity issue with remediation guidance to enforce HTTPS and validate certificates.

To remediate missing TLS when Django interacts with DynamoDB, enforce HTTPS and certificate validation in all AWS SDK calls. The following examples use boto3 within Django projects and demonstrate secure configurations.

1. Enforce TLS with boto3 session and explicit verification

Ensure the DynamoDB client is created with TLS verification enabled. Do not disable verification via verify=False.

import boto3
from django.conf import settings

def get_dynamodb_client():
    return boto3.client(
        'dynamodb',
        region_name=settings.AWS_REGION,
        aws_access_key_id=settings.AWS_ACCESS_KEY_ID,
        aws_secret_access_key=settings.AWS_SECRET_ACCESS_KEY,
        endpoint_url=settings.DYNAMODB_ENDPOINT,  # Must be https://
        verify=True  # Ensure TLS verification is enabled
    )

2. Use resource interface with secure endpoint

When using the resource interface, validate that the endpoint URL uses HTTPS and that custom configurations do not disable SSL checks.

import boto3
from django.conf import settings

def get_dynamodb_resource():
    # Ensure endpoint_url uses HTTPS
    return boto3.resource(
        'dynamodb',
        region_name=settings.AWS_REGION,
        aws_access_key_id=settings.AWS_ACCESS_KEY_ID,
        aws_secret_access_key=settings.AWS_SECRET_ACCESS_KEY,
        endpoint_url=settings.DYNAMODB_ENDPOINT,
        verify=True
    )

3. Centralize configuration and reject HTTP endpoints

In your Django settings, define allowed endpoint patterns and validate them at startup to prevent accidental HTTP usage.

# settings.py
AWS_REGION = 'us-east-1'
AWS_ACCESS_KEY_ID = 'YOUR_ACCESS_KEY'
AWS_SECRET_ACCESS_KEY = 'YOUR_SECRET_KEY'
DYNAMODB_ENDPOINT = 'https://dynamodb.us-east-1.amazonaws.com'  # Enforce HTTPS

# Validation helper
def validate_dynamodb_endpoint(url: str) -> bool:
    if not url.startswith('https://'):
        raise ValueError('DynamoDB endpoint must use HTTPS to enforce TLS')
    return True

# Call during initialization
validate_dynamodb_endpoint(DYNAMODB_ENDPOINT)

4. Secure custom HTTP session (if used)

If your Django code uses a custom requests.Session to talk to DynamoDB via a proxy or wrapper, enforce TLS explicitly.

import requests
from django.conf import settings

session = requests.Session()
session.verify = True  # Use system CA bundle
# Optionally provide a custom CA bundle path
# session.verify = '/path/to/ca-bundle.pem'

def make_dynamodb_request():
    response = session.get(settings.DYNAMODB_ENDPOINT + '/health', timeout=5)
    response.raise_for_status()
    return response.json()

5. CI/CD integration with middleBrick

Use the middleBrick GitHub Action to automatically fail builds if TLS misconfiguration is detected in OpenAPI specs or runtime scans. This ensures continuous enforcement of secure communication with DynamoDB.

# .github/workflows/api-security.yml
name: API Security Checks
on: [push]
jobs:
  middlebrick:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run middleBrick scan
        uses: middleBrick/action@v1
        with:
          url: https://api.example.com/openapi.json
          threshold: C