Response Splitting is an HTTP vulnerability where an attacker injects carriage return and line feed characters into a server response to create extra headers or a second response. It affects applications that place unvalidated input into response headers, and can be used for header injection, cache poisoning, or cross-site scripting.
How Response Splitting Works
Response splitting happens when an application passes untrusted input into an HTTP response header without proper validation or encoding. If an attacker can inject carriage return and line feed characters, the server may treat the input as the end of one header block and the start of another, creating unintended headers or even a second response. That turns a simple input-handling flaw into a protocol-level injection issue.
This matters because HTTP responses are shared infrastructure, not just application output. Once the response structure is corrupted, the attacker may be able to influence caching behaviour, content interpretation, or downstream browser handling in ways the application never intended. The vulnerability is especially dangerous where response headers are built dynamically from user-controlled values such as redirects, filenames, language settings, or reflection of request data.
Why Response Splitting Is Dangerous
The main danger is that the attacker is no longer limited to changing visible page content. By injecting a second header block or response, they can sometimes set cookies, alter cache directives, poison shared caches, or shape what other users receive. In some situations, response splitting can also support cross-site scripting by making the browser process attacker-controlled content as part of the response flow.
Because the flaw sits at the boundary between application logic and HTTP syntax, it can undermine multiple layers at once. A single unsanitized header value may affect browsers, reverse proxies, CDNs, and caching systems differently, which makes the impact hard to predict and easy to underestimate. That unpredictability is what makes response splitting more than a narrow injection bug.
Common Failure Conditions
Response splitting usually appears when developers trust data that should have been treated as opaque text. Typical failure points include redirect targets, reflected parameters, custom headers, and any code path that concatenates user input directly into header lines. If the application accepts line break characters, or decodes them after input validation, the protection can fail even when the code appears to filter obvious special characters.
Proxy chains and framework abstractions can make the issue harder to spot. A backend component may emit a header safely, while an intermediary normalises or reinterprets the output in a way that reintroduces header injection risk. That is why response-splitting bugs often survive partial fixes and why testing must cover the full response path, not only the first application layer.
Prevention and Verification
The correct defence is to prevent untrusted data from shaping HTTP syntax in the first place. Header values should be validated against a strict allowlist, encoded for the exact context they are used in, and rejected if they contain control characters. The safest design is to use response-building functions or framework APIs that separate header names, header values, and body content instead of concatenating raw strings.
Teams should also verify the behaviour with security testing that inspects raw responses, not just rendered pages. Attackers often probe for CRLF handling, cache effects, and browser interpretation differences, so tests should check the full stack, including proxies and caches. For broader guidance on web input abuse patterns, the Web Application Attacks Guide is a useful companion reference, and the OWASP view of OWASP API Security Top 10 helps place response manipulation alongside other injection and authorisation failures.
Risk and Threat Considerations
Response splitting is dangerous because it turns one user-controlled value into a way to shape how intermediaries and browsers process an entire HTTP exchange. That can enable cache poisoning, header injection, and in some cases script delivery through response manipulation.
Failure mechanism: The application accepts line break characters in a response header value, allowing an attacker to terminate the intended header and inject new headers or a second response.
Impact: Shared caches may store attacker-influenced content, users may receive altered responses, and browser-side handling may be manipulated to support phishing, session abuse, or cross-site scripting.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | Response splitting exploits unsafe output handling in header context. |
| V16 — Security Logging and Error Handling | Testing and detection of malformed response handling depend on logging and error visibility. | |
| Recommendation — Apply strict context-aware encoding and reject control characters before building response headers. Log malformed header attempts and review error paths that may expose response manipulation. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Header injection begins when unvalidated input reaches response construction. |
| SC-7 — Boundary Protection | Response splitting can affect intermediaries, caches, and browsers across trust boundaries. | |
| Recommendation — Validate all user-controlled values before they are used in HTTP response headers. Protect response-handling boundaries and inspect proxy and cache behaviour for header injection. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Response splitting is an application-layer exploit against internet-facing services. |
| Recommendation — Hunt for exploitation attempts against exposed web applications and correlate anomalous response patterns. | ||
Practitioner Guidance
What to watch for: Review any code that builds headers from request data, especially redirects, cookies, content-disposition values, and custom metadata. The highest-risk cases are those that pass through multiple frameworks or intermediaries, because a control that appears effective in one layer may fail later in the delivery path.
Governance implication: Treat response header construction as a security-sensitive interface, not a formatting task. Owners should require framework-safe header APIs, reject control characters consistently, and include response-splitting checks in web application testing and change review.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org