What is HTTP request smuggling?

In front of most applications sits a chain: a CDN or load balancer (front-end) forwards requests to the back-end server. Both must agree on where each request ends.

HTTP gives two ways to state body length: the `Content-Length` header and `Transfer-Encoding: chunked`. If the front-end and back-end handle a conflicting or malformed combination differently, they disagree on the boundary. The attacker exploits that disagreement to leave part of their request in the buffer, which attaches to the next request that comes through.

The attacker sends a request with ambiguous length headers (classic CL.TE or TE.CL desync):

• One server honours Content-Length, the other honours Transfer-Encoding, so a chunk of the attacker’s body is interpreted by the back-end as the start of the next request.
• That smuggled prefix can capture another user’s request (stealing their cookies/credentials), bypass front-end security controls, or poison the cache so other users receive attacker content.
• Modern variants exploit HTTP/2-to-HTTP/1 downgrade desyncs.

Examples shown for defensive context.

• Normalise and reject ambiguity: drop requests that contain both Content-Length and Transfer-Encoding, or malformed chunked encoding.
• Use HTTP/2 end-to-end (and avoid downgrading to HTTP/1 to the back-end), which removes most desync surface.
• Keep proxies, CDNs, and servers patched and consistently configured so they parse identically.
• Disable connection reuse to the back-end if the chain cannot be made consistent.
• Test the full proxy chain for desync, not just the application.