HTTP Request Smuggling
debt(d7/e7/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list specialist tools (burpsuite, owasp-zap, portswigger-smuggler) that can catch it, but these require deliberate, targeted security testing — they are not default linters or compile-time checks. The vulnerability is silent in normal operation and only surfaces under adversarial probing or careful security audits, placing it closer to d7 than d5. Automated scanning is possible but only if someone thinks to run smuggling-specific tooling.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix says to use HTTP/2 end-to-end between load balancer and PHP backend, which eliminates the ambiguity. However, this is not a single-line patch — it requires infrastructure changes (reconfiguring or upgrading the load balancer, ensuring the backend supports HTTP/2, verifying all intermediate proxies handle it consistently), touching multiple layers of the stack. This is a cross-cutting infrastructure change rather than a simple code fix.
Closest to 'persistent productivity tax' (b5). The vulnerability arises from the interaction between frontend proxy and backend server across the web/api contexts. Any change to the proxy layer, CDN configuration, or HTTP parsing libraries must consider smuggling implications. This imposes an ongoing awareness tax on teams managing the proxy/backend boundary, but it does not define the entire system's shape — teams not touching the HTTP stack are largely unaffected.
Closest to 'serious trap' (t7). The misconception field explicitly states that developers believe smuggling only affects high-traffic sites with complex proxy setups, but in reality any application behind a reverse proxy or CDN using HTTP/1.1 with differing Content-Length/Transfer-Encoding handling is vulnerable. This contradicts the intuitive mental model of 'I'm just a small app with a simple proxy,' and the attack mechanism (exploiting parsing disagreements between two compliant-but-inconsistent servers) is non-obvious and contradicts how developers normally think about HTTP request parsing.
Also Known As
TL;DR
Explanation
HTTP Request Smuggling exploits the ambiguity between how a front-end proxy and a back-end server interpret the boundary of an HTTP request. Conflicting Content-Length and Transfer-Encoding: chunked headers can cause an attacker-controlled prefix to be prepended to the next legitimate user's request. Consequences include cache poisoning, session hijacking, and bypassing security controls. Mitigations: use HTTP/2 end-to-end, configure servers to reject ambiguous requests, and ensure front-end/back-end use identical HTTP parsing libraries.
Common Misconception
Why It Matters
Common Mistakes
- Front-end and back-end using different HTTP parsing implementations with differing Content-Length/Transfer-Encoding handling.
- Not upgrading to HTTP/2 end-to-end — HTTP/2 eliminates the ambiguity that makes smuggling possible.
- Load balancers that silently ignore malformed Transfer-Encoding headers instead of rejecting them.
- Not testing for smuggling with tools like smuggler.py before deploying a new proxy layer.
Code Examples
// CL.TE smuggling — front-end uses Content-Length, back-end uses Transfer-Encoding:
POST / HTTP/1.1
Content-Length: 13
Transfer-Encoding: chunked
0
GET /admin <- Smuggled request prefix, prepended to next user's request# HTTP Request Smuggling — frontend and backend disagree on body length
# Attacker sends ambiguous CL + TE headers to inject a second request
# Prevention:
# 1. Use HTTP/2 end-to-end (no CL/TE ambiguity)
# 2. Normalise at the load balancer — reject requests with both headers:
# nginx: reject if both Content-Length and Transfer-Encoding present
if ($http_transfer_encoding && $content_length) { return 400; }
# 3. Keep nginx/HAProxy up-to-date — both have fixed desync bugs
# 4. PHP-FPM is not directly internet-facing — nginx acts as gatekeeper
# Ensure the gateway validates request framing
# Test: PortSwigger HTTP Request Smuggler (Burp Suite extension)