Cybersecurity glossary
What is HTTP Response Smuggling?
Learn what HTTP response smuggling is, how proxy and client parsing disagreements on response boundaries enable cache poisoning and XSS, and how it differs from response splitting.
Definition
HTTP response smuggling is an attack in which inconsistent parsing of HTTP response message boundaries between a server, proxy, CDN, and client causes one connection to deliver multiple responses or misaligned bodies, enabling cache poisoning, request hijacking, and cross-user data leakage.
Why HTTP response smuggling matters
Security teams often focus on inbound request smuggling. The outbound path matters just as much. CDNs, reverse proxies, and browsers each parse where a response ends. When they disagree, one TCP connection can deliver a victim’s bytes as part of an attacker’s page—or store a poisoned response in a shared cache.
HTTP response smuggling is the server-to-client analogue of request smuggling. It is less discussed than CRLF response splitting but equally dangerous when intermediaries reuse connections with ambiguous framing.
How response smuggling works
Identify a response parser mismatch
Find a proxy that honors Content-Length while the client honors chunked encoding on responses, or similar disagreements.
Trigger an ambiguous response
Cause the origin to emit a response with conflicting or malformed length framing.
Proxy consumes partial response
The intermediary closes or reuses the connection believing the message is complete.
Client sees extra bytes
The browser or cache interprets leftover bytes as a new response or attaches them to the next request’s answer.
Exploit cross-user effects
Poison caches, leak one user’s response to another, or inject content under a trusted URL.
Align outbound parsers
Normalize responses at the origin, patch intermediaries, and disable unsafe reuse on desync-prone paths.
Common impacts
Cache poisoning
A smuggled response is stored under a popular URL and served to all CDN visitors.
Cross-user response mix-up
Connection reuse causes one client to receive another user’s response tail as body content.
Security filter bypass
Inspection tools see a benign first response while clients execute smuggled content.
Trusted-origin XSS
Malicious HTML delivered from a domain victims trust, especially when cached at the edge.
Response smuggling vs splitting vs request attacks
| Term | Direction | Typical mechanism |
|---|---|---|
| HTTP response smuggling | Server → client | Proxy/client parsing disagreement on response boundaries (CL/TE, reuse) |
| HTTP response splitting | Server → client | CRLF injection in application-reflected response headers |
| HTTP request smuggling | Client → server | Proxy/origin parsing disagreement on request boundaries |
| HTTP request splitting | Client → server | CRLF or concatenation creating multiple inbound requests |
Prevention checklist
- Ensure origin, CDN, and load balancers agree on how response Content-Length and Transfer-Encoding are interpreted.
- Reject or normalize ambiguous response framing before responses leave the origin.
- Disable HTTP/1.1 keep-alive reuse on paths where parser equivalence cannot be verified.
- Keep reverse proxies, CDNs, and browser-facing gateways patched for known desync CVEs.
- Do not rely solely on CRLF filtering in application code—smuggling often needs no reflected headers.
- Send explicit, correct Content-Length or valid chunked encoding on every dynamic response.
- Test outbound desync in authorized assessments through the real CDN-to-browser path.
- Monitor caches for unexpected response bodies on high-traffic URLs and anomalous content-type mismatches.
Limits and pitfalls
Response smuggling research is newer and tooling less mature than request smuggling. Teams that hardened inbound paths may still leave outbound desync open on CDN cache layers.
Do not conflate response smuggling with response splitting. Splitting is an application bug (reflecting %0d%0a into headers). Smuggling is an infrastructure parser bug (two compliant-looking stacks disagree on message length). Fixes differ: encoding headers versus aligning proxy behavior.
The practical takeaway
HTTP response smuggling weaponizes outbound parser disagreement. When a CDN and a browser do not share one definition of where a response ends, attackers poison caches and mix user data across connections.
Harden the full server-to-client chain the same way you harden inbound traffic: reject ambiguity, align parsers, patch intermediaries, and test through production edges—not only against the origin directly.
Related security terms
HTTP Response Splitting
CRLF injection in application-built headers; distinct from intermediary response-boundary desync.
HTTP Request Smuggling
The inbound mirror of this attack—desync on request boundaries between proxy and origin.
Web Cache Poisoning
A primary impact when smuggled responses are stored under victim URLs.
Content Delivery Network (CDN)
An intermediary that must parse response boundaries consistently with origins and browsers.
Frequently asked questions
What is HTTP response smuggling in simple terms?
Response smuggling happens when a proxy and a browser disagree about where one HTTP response ends. Leftover bytes from one response can be interpreted as the start of the next response, poisoning caches or mixing data between users.
How is response smuggling different from response splitting?
Response splitting injects CRLF into headers the application reflects from user input. Response smuggling exploits inconsistent Content-Length, chunked encoding, or connection reuse handling between server, proxy, and client—without necessarily injecting CRLF in app code.
How is response smuggling related to request smuggling?
Both are desynchronization attacks on HTTP message boundaries. Request smuggling affects inbound traffic (client to server); response smuggling affects outbound traffic (server to client). The same CL/TE ambiguity patterns appear on the response path.
What can attackers do with response smuggling?
Poison shared caches with malicious content, cause one user’s response body to appear in another user’s session, bypass security filters, or deliver XSS from a trusted domain via cached split responses.
Does HTTP/2 prevent response smuggling?
HTTP/2 framing reduces classic HTTP/1.1 ambiguity on that hop, but downgrade gateways, HTTP/1.1 backends, and connection reuse across translation layers can still desync responses.
How do you prevent HTTP response smuggling?
Align response parsers across origin, CDN, and clients; reject ambiguous length fields; disable unsafe connection reuse; patch known desync CVEs; and test the full outbound path in authorized security assessments.
References
Explore authoritative guidance and frameworks related to http response smuggling.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.