HTTP Request Smuggling
HTTP request smuggling exploits disagreements between two chained devices about where one request ends and the next begins, letting an attacker prepend hidden requests into another user connection.
Definition
Request smuggling is a class of front-end and back-end desynchronization attacks. When a proxy and an origin parse conflicting request framing signals such as Content-Length versus Transfer-Encoding differently, surplus bytes from one request are interpreted as the start of the next. The smuggled prefix can hijack sessions, poison caches, or bypass internal access controls.
Context and scope
Relevant wherever layered proxies, load balancers, WAFs, or caches sit in front of application servers: CDNs, API gateways, corporate egress proxies. Documented extensively in web security research.
Common misconceptions
- Smuggling requires malformed requests from the attacker client only — the attacker is often a normal user; the desync lives between your own devices
- It is a legacy HTTP/1.1 problem — HTTP/2-to-HTTP/1.1 translation layers created a new, larger smuggling surface
- Disabling keep-alive stops it — persistence helps the attack but is not required in every variant
Anti-patterns
- Configuring front-end and back-end to trust different body-length headers without normalization
- Routing ambiguous framing headers through translation proxies without a validation policy
- Assuming the WAF blocks smuggling because it blocks obvious malformed requests
Related concepts
Related examples
Authoritative source
https://owasp.org/www-community/vulnerabilities/HTTP_Request_Smuggling
What it is
A chain of intermediaries must agree on request boundaries. When the front end honors one signal and the back end honors another, the tail of one request becomes an invisible head of the next request on a shared connection. The next request often belongs to a different, innocent user.
How it works
Classic variants abuse conflicting Content-Length and Transfer-Encoding headers, duplicate headers, or malformed chunk sizes. HTTP/2 downgrades introduce new vectors because content-length is implied by framing, and translation reinvents it. The smuggled prefix can carry a full second request that the back end attributes to the victim connection.
When to care
Any deployment with more than one HTTP-speaking hop should normalize framing before forwarding: reject conflicting or duplicate length headers, enforce a single Transfer-Encoding, and disable header names that drive the desync. Automated scanners exist, and several proxy pairs have documented desyncs.
Pitfalls
Smuggling often leaves faint traces: odd 400s, phantom 405s, or another user session acting strangely. Cache poisoning through a smuggled response can persist long after the attack. Fix in normalization middleware rather than patching individual gadgets.