What causes HTTP request smuggling?

A disagreement between two servers in a chain — typically a front-end proxy/CDN and a back-end app server — about where one request ends and the next begins. When one honors the Content-Length header and the other honors Transfer-Encoding: chunked, an attacker can craft a body that the two parse differently, leaving part of it to be prepended to the next connection's request.

What can an attacker actually do with a desync?

Prepend a hidden request onto another user's request — poisoning it, capturing their headers and session cookies, bypassing front-end security controls and WAF rules, and poisoning shared caches. Because it corrupts the boundary between requests on a reused connection, it can affect other users, not just the attacker.

How do I prevent request smuggling?

Make the whole chain parse boundaries identically: reject requests that contain both Content-Length and Transfer-Encoding, normalize or strip ambiguous headers at the edge, prefer HTTP/2 end to end (its framing is unambiguous), and keep proxies and servers patched. Don't reuse a connection to the back end for requests from different clients if you can avoid it.

HTTP Request Smuggling: When Two Servers Disagree on Where a Request Ends

Most web apps sit behind a chain: a CDN or reverse proxy in front, an application server behind. Both have to agree on one basic thing — where each HTTP request ends. Request smuggling happens when they don't.

HTTP gives two ways to state a body's length: the Content-Length header (a byte count) and Transfer-Encoding: chunked (length-prefixed chunks ending in a zero-size chunk). If an attacker sends both, and the front-end trusts one while the back-end trusts the other, they parse the request to different endpoints. The bytes one server thinks are still "body" are what the other server reads as the start of the next request — which belongs to some other user sharing that back-end connection.

The two classic desyncs

CL.TE — the front-end uses Content-Length, the back-end uses Transfer-Encoding. The front-end forwards the whole body; the back-end stops at the chunked terminator early and treats the remainder as a new request.
TE.CL — the reverse: the front-end honors chunked, the back-end honors Content-Length. The attacker sizes the chunk so that leftover bytes are queued for the next request on that connection.

Either way, the attacker's "leftover" bytes get prepended to the next request that flows over the reused connection. That victim request now carries the attacker's smuggled prefix.

What it buys an attacker

Bypass front-end controls. Security rules, auth, and WAF checks enforced at the proxy are skipped by the portion of the request the back-end sees but the proxy never inspected.
Capture other users' requests. A smuggled prefix can cause the victim's request — including their session cookie and headers — to be reflected back or stored where the attacker can read it.
Cache poisoning and request hijacking across users sharing the back-end connection, because the corruption is on the connection, not just the attacker's own request.

The fix: one unambiguous interpretation across the whole chain

Smuggling only exists when two hops disagree. Remove the ambiguity everywhere.

POST /search HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED=1

# Two length headers on ONE request. A front-end that honors
# Content-Length and a back-end that honors Transfer-Encoding
# disagree on where the body ends — the "SMUGGLED=1" bytes get
# prepended to the next request on the connection.
#
# Defense rule: a request containing BOTH headers is malformed.
# Reject it outright (400) at the very edge.

The principles

Never allow both length headers. A request with Content-Length and Transfer-Encoding is malformed — reject it at the edge with a 400.
Normalize framing at the front door. Strip or canonicalize ambiguous and obfuscated Transfer-Encoding values before anything is proxied downstream.
Go HTTP/2 end to end. Unambiguous framing removes the entire class of CL/TE desync.
Patch the chain. Smuggling is largely a parser-discrepancy bug; keeping proxies and app servers current closes known gaps.

The one line: request smuggling is two servers disagreeing about where a request ends — make the whole chain agree, and reject anything ambiguous at the edge.

Try it in the request smuggling simulation: craft a CL.TE payload, watch a hidden request prepend onto the next one, then apply edge validation and see the desync rejected. It shares DNA with web cache poisoning — both abuse how intermediaries handle your requests.