Cryptographic Failures in Django with Dynamodb

Django does not provide built-in field-level encryption for model attributes, and the AWS SDK for DynamoDB does not automatically encrypt data before it is stored. When developers store sensitive values such as authentication tokens, personally identifiable information (PII), or secrets in a DynamoDB table via Django, the absence of explicit cryptographic protection can result in data exposure. This risk is compounded when an API endpoint is instrumented to read or write these fields without validating the caller’s authorization, enabling BOLA/IDOR or BFLA/Privilege Escalation patterns to expose or modify cryptographic material.

DynamoDB itself supports encryption at rest using AWS-owned keys or customer-managed keys, but this protects storage, not the application runtime. If Django deserializes raw attribute values over an unencrypted channel or logs them insecurely, the data can be leaked through SSRF, insecure deserialization, or overly broad Property Authorization checks. For example, a DynamoDB response containing a plaintext password field returned by a Django view with weak authentication can be captured by an authenticated attacker leveraging IDOR to enumerate other users’ records.

Another common failure arises from the misuse of environment variables and AWS credentials in development. Developers may inadvertently commit configuration that grants broad DynamoDB permissions, while the Django app performs client-side encryption incorrectly, such as using deterministic schemes or weak key derivation. This can enable offline password cracking if the table is exposed. Insecure Consumption patterns can further amplify the impact by accepting unvalidated input that alters table names or key schemas, potentially redirecting writes to tables with weaker encryption or access controls.

LLM/AI Security checks are relevant here because system prompt leakage patterns can expose cryptographic configuration details embedded in application logic or comments. Active prompt injection probes may coerce a Django endpoint backed by DynamoDB to return stack traces or configuration snippets, revealing encryption implementation details. Output scanning for API keys and executable code is essential to detect accidental exposure of secrets in LLM responses that interact with or describe the API surface.

Compliance mappings are practical: findings tied to Cryptographic Failures often align with OWASP API Top 10 2023 — Broken Object Level Authorization (BOLA/IDOR), Security Misconfiguration, and Data Exposure; PCI-DSS requirements for encryption of cardholder data; and SOC2 controls around key management and access restrictions. middleBrick scans these 12 checks in parallel and maps findings to these frameworks, providing prioritized remediation guidance rather than attempting to fix the implementation itself.

To reduce cryptographic risk, enforce encryption before data reaches DynamoDB and validate permissions at the field level. Use envelope encryption with AWS KMS and ensure that sensitive fields are encrypted in the Django model layer, not relied upon DynamoDB server-side features alone. The following patterns illustrate secure handling.

1. Envelope encryption with AWS KMS and DynamoDB save/update in Django:

import json
import boto3
from django.conf import settings
from aws_encryption_sdk import encrypt, decrypt, KMSMasterKeyProvider

kms_key_arn = settings.AWS_KMS_KEY_ARN
master_key_provider = KMSMasterKeyGenerator(key_ids=[kms_key_arn])

def encrypt_value(plaintext: str) -> str:
    ciphertext, _ = encrypt(
        source=plaintext,
        key_provider=master_key_provider
    )
    return ciphertext.decode('utf-8')

def decrypt_value(ciphertext_b64: str) -> str:
    plaintext, _ = decrypt(
        source=ciphertext_b64.encode('utf-8'),
        key_provider=master_key_provider
    )
    return plaintext.decode('utf-8')

class UserProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    ssn_encrypted = models.TextField(db_column='ssn', null=True)

    def save(self, *args, **kwargs):
        if self.ssn_encrypted == '':
            self.ssn_encrypted = None
        if self.pk is None or self.ssn_encrypted is None:
            # Only encrypt when creating or when value is provided
            # Assume self.ssn_plain is set transiently for input
            if hasattr(self, 'ssn_plain') and self.ssn_plain:
                self.ssn_encrypted = encrypt_value(self.ssn_plain)
        super().save(*args, **kwargs)

    def to_dynamodb_item(self):
        return {
            'user_id': {'S': str(self.user_id)},
            'ssn_encrypted': {'S': self.ssn_encrypted} if self.ssn_encrypted else {'NULL': True}
        }

This approach ensures that values are encrypted before being serialized into the DynamoDB item map. The to_dynamodb_item method demonstrates how to map encrypted strings to DynamoDB attribute values without leaking plaintext in the request payload.

2. Controlled retrieval with authorization checks:

from django.core.exceptions import PermissionDenied
import boto3

def get_dynamodb_item(table_name, user_requesting_id, target_id):
    if user_requesting_id != target_id:
        raise PermissionDenied('You can only access your own record.')
    dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
    table = dynamodb.Table(table_name)
    response = table.get_key(Key={'user_id': {'S': str(target_id)}})
    item = response.get('Item')
    if item and 'ssn_encrypted' in item and item['ssn_encrypted'].get('S'):
        item['ssn_plain'] = decrypt_value(item['ssn_encrypted']['S'])
    return item

Always enforce BOLA/IDOR checks before retrieving items, and avoid returning decrypted fields unless the requester is explicitly authorized. This prevents attackers from leveraging IDOR to enumerate other users’ encrypted records and attempting offline attacks against deterministic ciphertext.

3. Secure handling of DynamoDB Streams and consumer patterns:

import base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def process_stream_record(record):
    # Validate event source and encryption context before decryption
    if record.get('eventName') not in ('INSERT', 'MODIFY'):
        return
    encrypted_blob = record.get('dynamodb', {}).get('NewImage', {}).get('ssn_encrypted', {}).get('S')
    if not encrypted_blob:
        return
    # Use envelope decryption with KMS data key caching for performance
    # Ensure strict input validation to prevent injection into downstream consumers
    # middleBike findings will highlight if PII appears in logs or error outputs

These examples focus on preventing Cryptographic Failures by integrating encryption into the Django application layer, validating permissions explicitly, and ensuring that DynamoDB interactions do not expose plaintext sensitive data. middleBrick’s LLM/AI Security checks can detect accidental leakage of encryption keys or configuration in prompts and outputs, complementing these runtime safeguards.