HTTP Request Smuggling Explained

Modern applications rarely talk to the internet directly. Requests pass through CDNs, load balancers and reverse proxies before reaching the application server. HTTP request smuggling exploits disagreements between these layers about where one request ends and the next begins.

The root cause

HTTP/1.1 offers two ways to indicate a request body's length:

• Content-Length: the body is exactly this many bytes.
• Transfer-Encoding: chunked: the body is sent in chunks, ending with a zero-length chunk.

If a request contains both, or contains them in ambiguous forms, the front-end and back-end may choose differently. One server thinks the request ended; the other thinks part of it belongs to the next request.

Classic variants

• CL.TE: the front-end uses Content-Length, the back-end uses Transfer-Encoding.
• TE.CL: the front-end uses Transfer-Encoding, the back-end uses Content-Length.
• TE.TE: both support Transfer-Encoding, but one can be tricked into ignoring it with an obfuscated header.
• HTTP/2 downgrade smuggling: the front-end speaks HTTP/2 to clients but rewrites requests as HTTP/1.1 to the back-end, and smuggled headers or lengths survive the translation.

What attackers achieve

The smuggled bytes are prepended to the next request on the same back-end connection, which may belong to another user. This can lead to:

• Bypassing front-end security controls, such as access restrictions on /admin enforced only at the proxy.
• Capturing other users' requests, including their cookies and tokens.
• Web cache poisoning, serving malicious responses to many users.
• Reflected XSS delivered to arbitrary users without them clicking a link.

How to prevent request smuggling

1. Use HTTP/2 end to end where possible, which has a single, unambiguous length mechanism.
2. Keep proxies and servers updated; many smuggling issues are fixed in parsers.
3. Normalise ambiguous requests at the front-end, or reject requests with both Content-Length and Transfer-Encoding.
4. Reject malformed headers rather than tolerating them.
5. Avoid relying solely on the proxy for access control; enforce authorisation in the application too.
6. Disable back-end connection reuse if you cannot otherwise eliminate ambiguity, accepting some performance cost.

Detecting request smuggling

Detection uses carefully crafted requests that cause timing differences or response mismatches when servers disagree. It must be done carefully, because poisoned connections can affect real users. Use safe detection techniques and test outside peak hours.

SecurityInfinity runs safe smuggling detection probes against your front-end infrastructure and reports confirmed desynchronisation with guidance for your specific stack. Start free.

Frequently asked questions

Does using a CDN prevent request smuggling?

Not automatically. A CDN is often one half of the disagreement. Major providers patch known issues, but your origin configuration still matters.

Is HTTP/2 immune?

HTTP/2 end to end largely eliminates classic smuggling, but downgrading HTTP/2 to HTTP/1.1 between layers can reintroduce it.

How severe is request smuggling?

Often high or critical, because it can affect other users and bypass security controls.