HTTP header splitting is an attack in which unsanitised input introduces carriage return and line feed characters into an HTTP header value. The injected line break creates extra headers or alters the message structure, which can let an attacker poison responses, bypass controls, or manipulate caches.
What HTTP Header Splitting Is
HTTP header splitting happens when attacker-controlled input reaches an HTTP header without proper sanitisation and includes carriage return and line feed characters. Because HTTP uses those characters to separate header lines, the payload can create new headers or change the structure of the response.
The danger is not just malformed syntax. Once an application lets an attacker alter header boundaries, the response can carry misleading cache directives, injected cookies, redirects, or content metadata that downstream browsers, proxies, and intermediaries may trust.
Why HTTP Header Splitting Matters
This issue sits in the family of response manipulation bugs, where a single unsafe input path can affect multiple parts of the HTTP message. It is especially serious when the vulnerable value is reflected into security-sensitive headers such as Location, Set-Cookie, or cache-related fields, because the resulting response can influence both client behaviour and shared infrastructure.
In practice, header splitting can become a stepping stone to cache poisoning, session confusion, or downstream injection effects. The exact impact depends on which header is tainted, how proxies normalise the response, and whether the application or edge layer strips line breaks consistently.
Common Failure Conditions
Header splitting usually appears when developers concatenate unsafely into response headers instead of validating and encoding at the boundary. The problem is often introduced by redirect parameters, filename values, user agents, or other fields that are convenient to echo back into the response.
It is most likely to succeed where the application stack treats CR and LF as ordinary characters until the final response is built, or where a proxy, framework, or custom middleware handles header construction differently from the application code. Small inconsistencies across layers can turn an otherwise obvious validation rule into a real exploit path.
Defensive Design Patterns
Preventing header splitting requires strict allowlisting of header values, rejection of control characters, and framework-safe APIs for setting response headers. Applications should treat header construction as a structured operation, not a string-building exercise, and avoid reflecting untrusted data into headers unless the format is explicitly constrained.
It also helps to review how reverse proxies, CDN layers, and application frameworks normalise header values, especially when redirects and caching are involved. A secure implementation should fail closed if an input contains line breaks, rather than trying to repair the value after it has already reached the header builder.
Risk and Threat Considerations
HTTP header splitting can let an attacker reshape a response in ways that are hard to spot during normal testing, especially when the injected header affects caching, redirects, or cookies. The risk is highest when the vulnerable header is reused by intermediaries that make trust decisions based on response metadata.
Failure mechanism: The attacker injects CRLF into a header value, causing the server or an intermediate component to parse the response as multiple headers instead of one controlled field.
Impact: That can enable response poisoning, cache manipulation, control bypass, or the injection of attacker-chosen response directives that alter how clients and proxies process the page.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | Header splitting alters HTTP message structure and response handling. |
| Recommendation — Validate and encode header values so response metadata cannot be broken by control characters. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Response integrity depends on preserving HTTP message structure in transit. |
| SI-10 — Information Input Validation | The attack is enabled by unsanitised input entering a header sink. | |
| Recommendation — Protect message integrity so intermediaries do not process attacker-altered header boundaries. Validate and reject CRLF-bearing input before it reaches any response-header construction path. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application-layer input handling and response construction are the core failure points. |
| Recommendation — Review header-generation code for unsafe string concatenation and enforce safe framework APIs. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Removed due to mismatch |
Practitioner Guidance
What to watch for: Audit every code path that writes to response headers, especially redirects, download responses, and any header built from request data. If a value can ever contain line breaks, it should be rejected before header construction rather than normalised afterward.
Governance implication: Treat header-setting APIs and edge-layer rewrite rules as security-sensitive controls. Teams should own them explicitly, because a small misuse in one service can create a response-integrity issue that propagates through caches, browsers, and downstream applications.
Related resources from NHI Mgmt Group
- How do HTTP header based capability models compare with SDK bound integrations for application authorization?
- What happens when HSTS is added through a meta tag instead of an HTTP response header?
- Why does a malformed HTTP/2 header sequence create denial of service risk for servers?
- How should security teams use HTTP response header scanning in a web security programme?
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