Replay Attack in Django with Cockroachdb

A replay attack occurs when an attacker intercepts a valid data transmission—such as an API request or a session token—and re-sends it at a later time to impersonate the original sender. In a Django application using Cockroachdb as the backend, the vulnerability is less about Cockroachdb itself and more about how Django handles idempotency, tokens, and timestamps when requests are repeated against a Cockroachdb-backed service.

Cockroachdb is a distributed SQL database that provides strong consistency and serializable isolation by default. While this helps avoid certain classes of race conditions, it does not prevent a replay attack at the application layer. For example, if Django issues a financial transfer or privilege escalation request over HTTPS without a nonce or timestamp, an attacker can capture the authenticated HTTP request (including any JWT, session cookie, or API key) and replay it. Because Cockroachdb preserves the order and correctness of committed transactions, the replayed request may be processed as a new, valid transaction, leading to duplicate operations or unauthorized state changes.

The risk is amplified when Django endpoints are stateless and rely on idempotency keys only at the infrastructure level (e.g., load balancers) rather than in application logic. Cockroachdb’s serializable guarantees do not protect against intentional duplicate submissions; they only ensure that concurrent transactions do not violate consistency rules. If Django does not validate that a request has been seen before—using a unique request identifier stored in Cockroachdb with an appropriate uniqueness constraint—a replayed POST to /transfer-funds/ or /change-email/ may be executed twice, causing financial loss or account compromise.

Additionally, if timestamps are used for request validity without care, time-window replay becomes feasible. An attacker can capture a signed request and, before its timestamp-based expiration, replay it within the valid window. Cockroachdb’s clock synchronization across nodes is strong, but application-level timestamp checks must be explicit and combined with one-time tokens to be effective. Without explicit replay protection in Django—such as storing request identifiers in Cockroachdb and rejecting duplicates—attackers can exploit predictable endpoints even when the database enforces strict serializability.

To mitigate replay attacks in Django with Cockroachdb, implement idempotency at the application layer. Use unique request identifiers (e.g., client-generated UUIDs or cryptographic nonces) and store them in Cockroachdb with a uniqueness constraint. Before processing a request, check whether the identifier has already been committed; if so, reject or return the original response.

Below is a concrete Django example using Cockroachdb with django-cockroachdb backend, including model definition and view logic.

import uuid
import hashlib
from datetime import datetime, timezone, timedelta

from django.db import models, transaction
from django.http import JsonResponse, HttpResponseBadRequest

# Model to store processed request identifiers
class ProcessedRequest(models.Model):
    idempotency_key = models.CharField(max_length=64, unique=True, db_index=True)
    response_body = models.JSONField()
    created_at = models.DateTimeField(default=datetime.now, db_index=True)

    class Meta:
        db_table = 'processed_requests'

# Utility to compute a stable key from request components
def compute_idempotency_key(request):
    payload = request.body or b''
    method = request.method
    path = request.path
    # Include a timestamp window (e.g., 5 minutes) to bound storage
    timestamp = datetime.now(timezone.utc).strftime('%Y-%m-%dT%H:%M')
    raw = f'{method}:{path}:{payload.decode(errors="ignore")}:{timestamp}'
    return hashlib.sha256(raw.encode()).hexdigest()

# Example view with replay protection
from django.views.decorators.http import require_POST
from django.views.decorators.csrf import csrf_exempt
import json

@csrf_exempt
@require_POST
def transfer_funds(request):
    data = json.loads(request.body)
    amount = data.get('amount')
    destination = data.get('destination')

    key = compute_idempotency_key(request)

    with transaction.atomic():
        # Try to insert the key; if duplicate, a unique constraint violation occurs
        try:
            # Use get_or_create to detect replay
            processed, created = ProcessedRequest.objects.get_or_create(
                idempotency_key=key,
                defaults={'response_body': {'status': 'processed', 'amount': amount, 'destination': destination}}
            )
            if not created:
                # Replay detected: return the original response
                return JsonResponse(processed.response_body, status=200)
        except Exception as e:
            return HttpResponseBadRequest({'error': str(e)})

    # Proceed with business logic only on first occurrence
    # Example: update balances in Cockroachdb via Django ORM
    # Assume Account model exists with appropriate fields
    try:
        # Account.objects.filter(...).update(balance=F('balance') - amount)
        response_data = {'status': 'success', 'amount': amount, 'destination': destination}
        ProcessedRequest.objects.create(idempotency_key=key, response_body=response_data)
        return JsonResponse(response_data, status=200)
    except Exception as ex:
        return JsonResponse({'error': str(ex)}, status=500)

In this example, the idempotency key is derived from the HTTP method, path, body, and a time window to avoid unbounded storage. The unique constraint on idempotency_key in Cockroachdb ensures that concurrent or replayed requests cannot insert duplicates, effectively preventing duplicate processing. For high-throughput APIs, consider adding a TTL (time-to-live) via a periodic cleanup job to remove old entries from the processed_requests table.

Additionally, enforce HTTPS and use short-lived authentication tokens to reduce the window for interception. Combine these Django-level protections with Cockroachdb’s strong consistency to ensure that even under distributed load, replayed requests are identified and rejected at the application layer.