What is HTTP request smuggling and why is it dangerous in reverse-proxy architectures?

HTTP request smuggling (also called HTTP desync) exploits a discrepancy in how a front-end proxy and a back-end server parse the boundary between HTTP/1.1 requests, specifically around the Content-Length (CL) and Transfer-Encoding: chunked (TE) headers.

HTTP/1.1 allows two ways to specify request body length: Content-Length (a fixed byte count) and Transfer-Encoding: chunked (body ends with a zero-length chunk). When a front-end and back-end disagree on which header to use to find the end of the request, a single TCP stream can be split into two different request interpretations: the front-end sees one request, the back-end sees a 'normal' request plus the beginning of a 'smuggled' second request that it associates with the next user's request.

Attacks enabled:

• Bypass security controls: the front-end proxy (WAF, load balancer) sees and filters one safe request, but the back-end sees a different, malicious one.
• Poison other users' requests: the smuggled prefix is prepended to the next legitimate user's request, potentially redirecting their response, stealing their cookies, or capturing their request body.
• Cache poisoning and credential capture.

Why hard to detect: happens at the connection level, bypasses per-request filtering, and requires specific version/config combinations.

Mitigations: use HTTP/2 end-to-end (which has no CL/TE ambiguity); disable TE on the back-end or normalize headers at the proxy; keep proxy and back-end in sync on the HTTP parsing spec; use a WAF with desync-awareness; validate with tools like http-request-smuggler.