HTTP Response Splitting
Summary
HTTP response splitting (CWE-113/CWE-434's response-side sibling) is the specific, more severe outcome of CRLF injection: instead of just adding one extra header to a response, the attacker injects enough carriage-return/line-feed sequences to terminate the entire headers block early and start writing content the server never intended to send. Because an empty line is what tells an HTTP client "the headers are done, the body starts now," an attacker who can smuggle \r\n\r\n into a header value can forge that boundary themselves, then supply their own fabricated body content immediately after it. If the connection is being reused (kept alive) or sits behind a caching proxy, that fabricated content can end up served to a different, later request entirely, letting an attacker plant content that looks like it came from the real server for a victim who never sent the malicious request themselves.
Top Affected Components / Targets
- Any endpoint that reflects user input into a response header, particularly redirect endpoints writing to
Location - Applications sitting behind a caching proxy or CDN, where a split response can be cached and served to other users
- Any response path with a keep-alive connection, where a split response can affect the next request read from the same socket
Common Attack Vectors
- Inject a CRLF sequence followed by a second CRLF pair and a fabricated HTML body into a header-reflected parameter, then check whether the raw response contains that fabricated content as if it were the real response body
- Combine with a caching layer: if the split response is cacheable, a single malicious request can poison what subsequent, entirely unrelated visitors receive for that same cached URL
Common Payloads
%0d%0a%0d%0a<html>fabricated attacker-controlled body</html>%0d%0aSet-Cookie: session=attacker-value%0d%0a%0d%0a<html>...</html>combining a forged header with a full split body
Detection Strategy
Inject a CRLF sequence, a second CRLF pair to terminate the headers block, and a unique marker string into any parameter suspected of reaching a response header, then check the raw response for that marker appearing in what should be the response body, after a header section that ends prematurely. This is a stronger, more conclusive version of the basic CRLF header-injection check: rather than just confirming an extra header line, it confirms the entire response structure can be hijacked.
Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.
False-Positive Notes
- As with basic CRLF injection, confirmation requires the marker to parse as genuinely separate content following a real header/body boundary, not merely be reflected as literal text inside an existing header's value.
- A framework that decodes the CRLF sequence but then re-encodes or strips it before writing the response will not produce genuine response splitting.
How to Test
Manual Testing Methodology
Here is a systematic approach to identifying HTTP Response Splitting vulnerabilities in a target application.
Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.
Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.
Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For HTTP Response Splitting specifically, submit %0d%0a (and raw \r\n where the transport allows it) followed by a new header name/value or a fake log line into every parameter that ends up reflected in a response header, Set-Cookie value, redirect target, or logged field.
Compare the response against your baseline, looking specifically for an extra, attacker-defined header appearing in the raw HTTP response, a split response body, or a forged entry appearing in application logs.
Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For HTTP Response Splitting, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.
Real-World Impact
Real-World Impact
CRLF and HTTP header injection let an attacker insert carriage-return/line-feed sequences into a value that ends up in a raw HTTP header or a log line, splitting what should be a single header into multiple, or a single log entry into several. In a header context, this can inject entirely new response headers, split the response into two, or plant content the application never intended to serve — including a second, attacker-controlled response body.
The practical exploits built on this primitive include HTTP response splitting (poisoning what an intermediate cache stores and serves to other users), session fixation via an injected Set-Cookie header, and open-redirect-adjacent phishing via an injected Location header — the specific impact depends on which header ends up attacker-controlled.
In logs specifically, CRLF injection enables log forging: an attacker can fabricate fake log entries designed to mislead an investigator or hide evidence of the real attack among plausible-looking noise.
Prevention & Remediation
Prevention and Secure Coding
Preventing HTTP Response Splitting takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.
Reject CR/LF in header and log values outright. Strip or reject \r and \n characters from any user input that will be placed into an HTTP header value or a log line — don't attempt to escape them, reject the input.
Use framework header-setting APIs. Set headers and cookies through the framework's own API (which typically encodes or rejects invalid characters automatically) rather than concatenating raw strings into a header block.
Validate redirect and cookie values against a strict format. Where a value must go into a Location or Set-Cookie header, validate it against an allowlist format before use, not just against CR/LF.
Structured logging. Use a structured (e.g. JSON) logging format rather than freeform string concatenation, which makes log forging via embedded newlines far harder to pull off convincingly.