Replay Attack in Django with Firestore

A replay attack occurs when an attacker intercepts a valid request and retransmits it to produce an unauthorized effect. In a Django application that uses Google Cloud Firestore as its backend, specific integration patterns can expose endpoints to this risk. The combination of HTTP-based API calls, predictable or missing nonces, and the idempotent nature of some Firestore operations creates conditions where replayed requests appear legitimate to Firestore and to Django’s view logic.

Consider a Django view that creates a Firestore document using a client-supplied identifier, such as a transaction ID or a user-provided order number. If the request includes an authentication token or API key in headers but lacks a one-time value (nonce) or timestamp, an attacker can capture a valid POST request containing a document write and simply retransmit it. Because Firestore writes with the same document ID are idempotent — the second write overwrites the first — the replayed request appears as a normal operation to Firestore. Django may also process the request as a new action if it only validates the presence of a token and does not track request uniqueness. This can lead to duplicate records, unauthorized state changes, or privilege escalation when the replayed request elevates permissions or modifies sensitive data.

Django middleware and Firestore client configurations can inadvertently encourage replay-friendly behavior. For example, using Firestore in Datastore mode with auto-generated IDs does not inherently protect against replay if the application logic relies solely on client-supplied identifiers or timestamps without server-side validation. Additionally, Django REST framework endpoints that accept JSON payloads and write them directly to Firestore documents without verifying request origin or freshness increase exposure. Attack vectors such as credential leakage in logs or insecure transmission further amplify the risk, especially when TLS is misconfigured or tokens are reused across requests. The lack of built-in replay protection in standard Firestore client libraries means developers must implement nonces, timestamps, and server-side deduplication explicitly.

Real-world examples align with common OWASP API Top 10 risks such as Broken Object Level Authorization (BOLA) and Security Misconfiguration. In an integration where Django serves as an API layer to Firestore, missing idempotency keys or inconsistent timestamp windows allow attackers to manipulate state through repeated requests. The Firestore security rules may permit writes based on request authentication alone, without ensuring request uniqueness. This gap is exploited when attackers capture requests from authenticated sessions and replay them to create or modify resources. Continuous monitoring and scanning with tools that understand API behavior, such as middleBrick, can surface these patterns by correlating request anomalies and missing idempotency controls across Firestore-integrated Django services.

Mitigating replay attacks in a Django and Firestore architecture requires server-side controls that enforce uniqueness and freshness for each request. The following patterns demonstrate concrete fixes using the official Google Cloud Firestore client for Django-compatible Python environments.

1. Use idempotency keys with Firestore transactions

Generate a unique idempotency key on the server for each write operation and store it in Firestore to detect duplicates. This ensures that replayed requests with the same key are ignored or handled safely.

import uuid
from google.cloud import firestore
from django.http import JsonResponse

db = firestore.Client()

def create_transaction_view(request):
    if request.method != 'POST':
        return JsonResponse({'error': 'Method not allowed'}, status=405)

    data = request.body  # assume JSON payload parsed appropriately
    idempotency_key = str(uuid.uuid4())

    transaction_ref = db.collection('transactions').document(idempotency_key)
    with db.transaction():
        snapshot = transaction_ref.get()
        if snapshot.exists:
            return JsonResponse({'error': 'Duplicate request'}, status=409)
        transaction_ref.set({
            'payload': data,
            'created_at': firestore.SERVER_TIMESTAMP,
            'idempotency_key': idempotency_key
        })
    return JsonResponse({'status': 'created', 'idempotency_key': idempotency_key}, status=201)

2. Enforce server-side timestamps and short validity windows

Require a server-generated timestamp for each request and reject requests with timestamps outside an acceptable window. This prevents attackers from reusing old requests indefinitely.

from google.cloud import firestore
from django.utils import timezone
from datetime import timedelta
import json

db = firestore.Client()

def process_order_view(request):
    try:
        body = json.loads(request.body)
        client_ts = body.get('timestamp')
        if not client_ts:
            return JsonResponse({'error': 'Missing timestamp'}, status=400)
        # Convert client timestamp to datetime for comparison
        # For simplicity, assume client_ts is ISO format string
        from datetime import datetime
        client_dt = datetime.fromisoformat(client_ts.replace('Z', '+00:00'))
        server_dt = timezone.now()
        if abs((server_dt - client_dt).total_seconds()) > 30:
            return JsonResponse({'error': 'Stale request'}, status=408)
    except Exception:
        return JsonResponse({'error': 'Invalid timestamp'}, status=400)

    # Proceed with Firestore write using server timestamp
    doc_ref = db.collection('orders').document()
    doc_ref.set({
        'data': body,
        'received_at': firestore.SERVER_TIMESTAMP
    })
    return JsonResponse({'order_id': doc_ref.id}, status=200)

3. Validate and scope Firestore security rules and Django permissions

Ensure Firestore rules and Django permissions align to reject requests that lack proper context. Combine request-level nonces with user-specific constraints to limit the impact of captured credentials.

# Firestore security rule example (not executable in Django but illustrative)
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/transactions/{transactionId} {
      allow write: if request.auth != null
        && request.auth.uid == userId
        && request.time == request.resource.data.timestamp;
    }
  }
}

In Django, enforce user ownership checks before writing to Firestore and use middleware to verify nonces stored in cache or Firestore for the session window.