Cybersecurity glossary
What is HTTP Header Injection?
Learn what HTTP Header Injection is, how CRLF sequences let attackers split or poison headers, what impacts follow—from session fixation to cache poisoning—and how to prevent unsafe header construction.
Definition
HTTP Header Injection is a vulnerability in which untrusted input containing carriage return and line feed characters is written into HTTP headers, allowing attackers to insert new headers, split responses, or otherwise manipulate the HTTP message structure.
Why HTTP Header Injection matters
HTTP messages are structured text (or binary frames that still carry header fields). The boundary between headers is defined by line breaks. If an application copies user input into a header value and that input contains %0d%0a / \r\n, the attacker can invent new headers the developer never intended.
HTTP Header Injection (often called CRLF injection) turns a simple “put the next URL in Location” feature into session fixation, cache poisoning, or response splitting. It is a classic reminder that protocol metacharacters need the same respect as SQL quotes or HTML angle brackets.
How header injection works
Find a dynamic header
Locate redirects, file download names, cookies, or custom headers influenced by request data.
Inject CRLF sequences
Submit %0d%0a or raw control characters to break out of the intended header value.
Insert attacker headers
Add Set-Cookie, Location, or spoofed security headers after the break.
Optionally split the response
Additional CRLFs can terminate headers and start a body the attacker controls.
Abuse interpreters
Browsers, caches, or logs may honor the injected structure.
Achieve impact
Session fixation, XSS, cache poison, or policy bypass follows.
Common impact paths
Session fixation
Injected Set-Cookie can plant a known session identifier for a later takeover.
Cache poisoning
Shared caches may store attacker-controlled responses keyed under a victim URL.
Security header sabotage
Injected or overwritten CSP/HSTS-related behavior can weaken browser protections.
Open redirect amplification
CRLF in redirect handling can turn a Location bug into a broader response attack.
Prevention
| Practice | Detail |
|---|---|
| Use safe APIs | Set headers through framework methods that reject CR/LF rather than string concatenation. |
| Allowlist values | Redirect targets and filenames should match strict patterns, not arbitrary strings. |
| Reject control chars | Fail closed if input contains \r, \n, or other HTTP delimiter bytes. |
| Avoid raw responses | Custom socket writers recreate decades of header bugs; prefer battle-tested servers. |
- Audit all code paths that set Location, Set-Cookie, Content-Disposition, and custom headers from input.
- Add unit tests that attempt %0d%0a injection and expect rejection.
- Normalize and validate redirect destinations against an allowlist of known sites/paths.
- Ensure logging libraries cannot be turned into response or file injection sinks via CRLF.
- Review reverse proxies for header smuggling interactions with upstream apps.
- Keep web frameworks updated; many have hardened header setters over time.
- Treat encoded variants (%0d, %0a, Unicode line separators) as hostile in header contexts.
- Include header injection cases in DAST and code review checklists.
The practical takeaway
HTTP Header Injection abuses CRLF characters to escape a header value and reshape the HTTP message. The fix is to stop building headers from raw untrusted strings and to reject protocol metacharacters outright.
If user input can reach a header writer, assume attackers will try to write the next header for you—unless your APIs make that impossible.
Related security terms
HTTP Request Splitting
A closely related message-smuggling style issue involving crafted request boundaries.
Open Redirect
Often shares root causes when Location headers are built from untrusted input.
Session Fixation
A possible outcome when attackers inject Set-Cookie headers.
Cross-Site Scripting (XSS)
Response splitting can sometimes be leveraged toward XSS in downstream interpreters.
Frequently asked questions
What is HTTP Header Injection in simple terms?
If an application puts user input into an HTTP header and does not block newline characters, an attacker can break out of that header and add their own headers or even start a fake response body.
What are CRLF characters?
CRLF means carriage return and line feed (`\r\n`), the standard line ending that separates HTTP headers. Injecting them lets attackers control message structure.
What can attackers achieve with header injection?
Impacts include session fixation via Set-Cookie, cache poisoning, cross-site scripting via split responses, security header overwrites, and open redirect abuse through Location manipulation.
Is header injection the same as HTTP request smuggling?
Not exactly. Header injection focuses on untrusted data entering header values. Request smuggling usually abuses inconsistent parsing of Content-Length and Transfer-Encoding between intermediaries. They can overlap in impact.
How do you prevent HTTP Header Injection?
Never concatenate untrusted input into raw headers. Use framework APIs that encode or reject control characters, validate allowlists for values like redirects, and strip CR/LF from any residual dynamic header data.
Where do these bugs usually appear?
Redirect targets, file download filenames (Content-Disposition), logging of headers, proxy forwarding headers, and custom analytics headers built from query parameters.
Can modern frameworks still be vulnerable?
Yes, especially when developers bypass helpers and write raw socket/HTTP responses, or when older middleware still allows CR/LF through.
References
Explore authoritative guidance and frameworks related to http header injection.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.