HTTP Response Splitting
Response splitting injects CRLF into header values so the attacker appends headers or a body, poisoning caches and enabling cross-site scripting.
Definition
HTTP response splitting is an attack in which carriage return and line feed characters smuggled into a header value cause the server to emit extra headers or a second response that the attacker controls.
Context and scope
It arises when user input such as a redirect target or a cookie value is placed into headers without stripping control characters.
Common misconceptions
- modern frameworks always reject newline characters in headers
- response splitting cannot affect shared caches
Anti-patterns
- reflecting a query parameter directly into a Location header
- trusting that an upstream proxy will normalise header values
Related concepts
Related examples
Authoritative source
https://owasp.org/www-community/attacks/HTTP_Response_Splitting
Definition
HTTP response splitting is an attack in which carriage return and line feed characters smuggled into a header value cause the server to emit extra headers or a second response that the attacker controls.
It arises when user input such as a redirect target or a cookie value is placed into headers without stripping control characters. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
The injected break ends the current header block, so everything after it becomes either a new header or, with a second break, the body of a forged response.
Effects range from cache poisoning that serves the crafted response to other users, to cross-site scripting when the injected body contains markup.
Trade-offs and alternatives
Reject or strip control characters at the boundary before any value reaches a header, and validate redirect targets against an allowlist. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that modern frameworks always reject newline characters in headers. Another is that response splitting cannot affect shared caches. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to reflecting a query parameter directly into a Location header and to trusting that an upstream proxy will normalise header values. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Rainbow Tables and Lookup Attacks, Password Salting, Authenticated Encryption (AEAD).