HTTP header injection is a web attack where untrusted input is inserted into an HTTP response or request header. If an application fails to sanitise carriage return and line feed characters, an attacker can add, split, or alter headers, which can enable cache poisoning, response splitting, open redirects, or cookie manipulation.
What HTTP Header Injection Does to a Request or Response
http header injection is dangerous because headers are part of the protocol boundary, not ordinary page content. When untrusted data reaches a header field, it can change how browsers, caches, proxies, and downstream services interpret the message.
The practical consequence is control-plane abuse through data that should never have been allowed to shape transport metadata. That is why header injection can create effects far beyond the original input field, especially when the application reflects user-controlled values into redirects, cookies, or proxy-related headers.
How Injection Happens in the Header Layer
The classic failure mode is unsanitised carriage return and line feed characters, which let an attacker terminate one header and start another. Even a small parsing mistake can turn a single application-controlled header into multiple attacker-controlled headers.
This is especially risky in code paths that build response headers dynamically, such as redirect targets, filename downloads, cache directives, or forwarded host values. A secure implementation must treat header construction as structured output, not string concatenation.
Header injection is closely related to response splitting, but the effect depends on the surrounding stack. Some components will reject malformed bytes early, while others may pass the payload farther downstream, where reverse proxies, caches, or browsers may apply the attacker’s injected metadata.
Security Consequences and Abuse Paths
Once an attacker can alter headers, the impact can include cache poisoning, open redirects, cookie manipulation, content-type confusion, and in some environments even session or security control weakening. The exact outcome depends on which header is influenced and which intermediaries trust it.
A poisoned cache entry can serve malicious or misleading content to other users. A forged redirect header can send victims to attacker-controlled destinations. If cookie or response metadata is manipulated, the attack may alter authentication flow, session handling, or browser-side trust decisions.
For readers who want a broader view of web application risk patterns, the OWASP Top 10 remains the standard baseline for understanding how input-handling failures become exploitable web risks.
Detection and Hardening at the Edge
Defence starts with strict output handling: never let raw user input determine header names or header values without validation, encoding, or allowlisting. The most robust pattern is to use framework-supported header APIs that enforce header syntax and reject control characters before emission.
It also helps to review reverse proxies, frameworks, and application gateways for header normalisation behaviour, because one layer may sanitise while another reintroduces risk. Security testing should include header injection cases, especially where applications accept user-controlled URLs, filenames, host values, or redirect parameters.
For adjacent hardening issues such as host validation, forwarded header trust, cache behaviour, and security header design, NHIMG’s Host Header Attacks and Validation Guide and Security Headers Guide provide useful defensive context.
When the same application also has script-delivery or browser trust concerns, the Cross-Site Scripting (XSS) Prevention Guide is a helpful companion because header mistakes and client-side injection often reinforce one another.
Risk and Threat Considerations
HTTP header injection matters because headers influence caching, routing, redirects, cookies, and browser behaviour. A successful exploit can turn a single request into a broader trust failure that affects other users, intermediary infrastructure, or security controls downstream.
Failure mechanism: The attacker supplies control characters or other malformed input that breaks header boundaries, allowing new headers to be created, altered, or split before the response reaches the client or an intermediary.
Impact: The resulting message can poison caches, redirect users, weaken cookie handling, or change how a browser or proxy interprets the response, creating cross-user and cross-session security exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 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 | V12 — Secure Communication | Header injection abuses HTTP message handling, which falls within secure transport and response construction. |
| V16 — Security Logging and Error Handling | Header parsing failures and malformed input should be logged and handled safely to support detection. | |
| Recommendation — Validate and encode HTTP headers so user input cannot change protocol semantics. Log rejected header payloads and malformed response construction events for investigation. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The term is rooted in failure to validate untrusted input before it is placed into headers. |
| SC-23 — Session Authenticity | Cookie and redirect manipulation can undermine session trust and response authenticity. | |
| Recommendation — Apply input validation to prevent control characters and other dangerous data from reaching headers. Protect session-related headers so attackers cannot alter browser or session handling. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Header injection often emerges from unsafe framework, proxy, or gateway header handling. |
| Recommendation — Harden header processing and reject malformed metadata before it reaches clients or intermediaries. | ||
Practitioner Guidance
What to watch for: Treat any code path that writes headers from dynamic input as a review hotspot, especially redirects, host-derived links, download filenames, and proxy-aware logic. These are the places where a parsing flaw becomes a protocol-level injection issue.
Governance implication: Ownership should sit with application security and platform teams together, because the fix is often split across application code, framework defaults, reverse proxies, and CDN or cache configuration. If any one layer is permissive, the control can still fail.
Practitioner takeaway: The safest posture is to make header values boring, explicit, and fully controlled by code, not by request data.
Related resources from NHI Mgmt Group
- Why does HTTP header injection create a broader account takeover risk than a simple response manipulation issue?
- What breaks when HTTP header injection is allowed to reach request boundaries?
- HTTP Response Header Injection
- What breaks when a dependency CVE depends on header injection but the runtime blocks it?