Http Request Smuggling in Django with Firestore

Http Request Smuggling becomes relevant in a Django + Firestore stack when an application sits behind a front-end proxy (load balancer, API gateway, or WAF) and constructs Firestore requests using data derived from the raw HTTP message. Because Firestore operations are typically authorized via service account credentials and invoked from backend code, the smuggling risk is not in Firestore itself but in how Django parses and forwards requests to downstream services that eventually call Firestore.

In Django, common triggers include inconsistent handling of Content-Length and Transfer-Encoding headers when a middleware or view builds HTTP requests to other services (for example, a separate admin API that writes to Firestore). If Django’s WSGI server or a reverse proxy normalizes headers differently than the downstream service, an attacker can craft a request where the proxy interprets one message boundary and Django interprets another. This can cause a smuggled request to be forwarded to an internal Firestore-integrated endpoint that trusts the caller because it originates from the host itself.

Consider a Django view that accepts a JSON payload, enriches it with authentication data, and then calls a separate internal service to store data in Firestore using the Admin SDK. If the view forwards the raw or partially trusted request to the internal service without revalidating headers, a smuggled request can cause the internal service to execute unintended Firestore writes. An example attack chain:

• An attacker sends a request with both Content-Length: 28 and Transfer-Encoding: chunked, smuggling a second request that targets an internal endpoint like /internal/import.
• The front-end proxy treats the first request as the primary; Django, depending on server and middleware configuration, may process the smuggled chunked request as a separate logical request.
• The internal endpoint uses Firestore Admin credentials to write data, and because it trusts the caller (it’s internal), the smuggled request results in unauthorized data modification or data leakage.

Because Firestore rules do not protect backend service-to-service calls made with Admin credentials, the onus is on Django to ensure that request parsing is consistent with the network perimeter and that forwarded requests do not carry smuggled content. The scan coverage in this environment includes checks for inconsistent header handling and exposure of internal endpoints that interact with Firestore.

Remediation focuses on strict HTTP parsing in Django and secure patterns when making backend calls to services that use Firestore. Do not rely on Firestore security rules to protect backend Admin operations; instead ensure Django never forwards or processes ambiguous HTTP messages that could smuggle requests.

1. Enforce strict header parsing in Django middleware and reject requests that contain both Content-Length and Transfer-Encoding. This prevents malformed smuggling attempts from being interpreted differently by Django and the proxy.

import logging
from django.utils.deprecation import MiddlewareMixin
class StrictHeaderMiddleware(MiddlewareMixin):
    """Reject requests that contain both Content-Length and Transfer-Encoding."""
    def process_request(self, request):
        content_length = request.META.get('CONTENT_LENGTH')
        transfer_encoding = request.META.get('HTTP_TRANSFER_ENCODING')
        if content_length and transfer_encoding:
            logging.warning('Smuggling risk: conflicting headers', {
                'path': request.path,
                'content_length': content_length,
                'transfer_encoding': transfer_encoding,
            })
            from django.http import HttpResponseBadRequest
            return HttpResponseBadRequest('Conflicting Content-Length and Transfer-Encoding')

2. When Django calls an internal service that writes to Firestore, use explicit configuration for the HTTP client instead of forwarding raw request data. For example, use requests with strict settings and avoid passing ambiguous headers to the downstream service.

import requests
def call_internal_firestore_service(payload, admin_token):
    url = 'https://internal-api.example.com/v1/write-firestore'
    headers = {
        'Authorization': f'Bearer {admin_token}',
        'Content-Type': 'application/json',
        # Never forward Transfer-Encoding or original Content-Length from the client
    }
    # Ensure strict Content-Length is set by requests; do not forward client-controlled hop-by-hop headers
    resp = requests.post(url, json=payload, headers=headers, timeout=5)
    resp.raise_for_status()
    return resp.json()

3. Use Django settings to restrict which hosts can reach internal endpoints and ensure that Firestore-admin logic is not exposed to unauthenticated or cross-origin calls. Apply the ALLOWED_HOSTS setting tightly and protect internal routes with explicit authentication, not just network-level assumptions.

# settings.py
ALLOWED_HOSTS = ['api.example.com', 'internal.service.example.com']
# views.py
from django.http import JsonResponse
def firestore_write_view(request):
    if not request.user.is_authenticated:
        return JsonResponse({'error': 'unauthorized'}, status=401)
    # process and write to Firestore using Admin SDK with controlled credentials
    return JsonResponse({'status': 'ok'})

4. Validate and sanitize all inputs before using them in Firestore operations. Use Django form and model validation to ensure that data written to Firestore does not rely on unchecked proxy-derived metadata that could be influenced by a smuggled request.

from django import forms
class FirestoreEntryForm(forms.Form):
    document_id = forms.CharField(max_length=255)
    data = forms.JSONField()

# In a view
def safe_write(request):
    form = FirestoreEntryForm(request.POST)
    if not form.is_valid():
        return JsonResponse(form.errors, status=400)
    # Proceed with Firestore write using validated form.cleaned_data