Home / Knowledge hub / HTTP header injection
Knowledge hub
HTTP header injection
Slipping line breaks into input so an attacker adds headers to your response.
What it means
HTTP header injection happens when your application puts user input into a response header without checking it. If the input contains line break characters, the attacker can end the header early and write new headers of their own, or even start the body.
Headers are lines of text separated by a carriage return and line feed. Anything that lets an outsider insert those two characters into a header value lets them add lines to your response. Your application then forwards the extra lines as if they were its own, and the browser or cache obeys them.
Why it matters
Added headers can set cookies, change caching, redirect visitors or turn off a protection. Where a cache or proxy sits in front, a forged response can be stored and served to other visitors. In the older, fuller form the response can be split in two, which MITRE tracks as CWE-113.
The effect depends on the feature, but it tends to end in a visitor being sent somewhere else, a cookie being planted, or poisoned pages reaching many people from a single request. It is also a stepping stone: a planted cookie can be used to fix someone's session.
How it shows up
You meet it where input flows into a header: redirect targets in a Location header, a language or return address copied into a cookie, a download file name in Content-Disposition, or a value echoed in a custom header. Many current frameworks refuse line breaks in header values, but older ones and hand-built responses may not.
Never place raw input into a header. Strip or reject carriage return and line feed characters, validate values against an allowlist, and use your framework's own functions for redirects and cookies. Test by sending encoded line breaks in each parameter that appears in a header. See CRLF injection and open redirects.
Questions people ask
HTTP header injection, answered
What is the difference between header injection and CRLF injection?
CRLF injection is the underlying technique: inserting carriage return and line feed characters. Header injection is one use of it, where the target is an HTTP response header.
The same trick also works on logs, emails and other line-based formats.
Is HTTP response splitting the same thing?
It is the more severe form. The attacker inserts enough line breaks to end the response and begin a second, forged one.
Modern servers and frameworks often block it, but older stacks may not.
Do modern frameworks prevent it?
Many reject line breaks in header values by default, which has made it rarer. Not all do, and custom code that writes headers directly may bypass the protection.
Check your own stack rather than assume.
What should we do with a redirect address from input?
Validate it against a list of permitted destinations and use your framework's redirect function. Do not build the header string yourself.
That also helps protect against open redirects. A tested redirect function is safer than any string you assemble yourself.
How do we test for header injection?
Send encoded line breaks in parameters that show up in headers, then check whether a new header appears in the response.
Use a harmless test header so the proof is clear and nothing is changed.
Related
Terms that sit next to this one
CRLF injection
Using carriage return and line feed characters to split a response or a log line.
Email header injection
Input that adds extra recipients or headers to an email your app sends.
Open redirect
A page that forwards visitors to any address handed to it in the URL.
Injection
Input that ends up running as a command instead of being read as text.
Security headers
Response headers that switch on browser protections against common web attacks.
Can input add a line to your response?
Headers built from input are easy to miss in review. We test every parameter that reaches a response header and report what appeared, with the request and response that prove it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.