Bridge WAF
CRLF injection: line breaks where data should be
CRLF stands for carriage return and line feed, the two characters that end a line in HTTP headers and in many log formats. CRLF injection is an attack in which input containing them reaches a header or a log line, so the attacker can start a new header, a new log entry or, in the worst case, a whole new HTTP response. Its relatives, response splitting and host header injection, abuse the same trust in what arrives in headers.
Quick facts
- CRLF
- Carriage return and line feed, the line ending in HTTP/1.1 headers
- OWASP category
- A05:2025 Injection
- Where it lands
- Redirect locations, cookies set from input, custom headers, log files
- Main fix
- Refuse or strip line breaks in any value that becomes a header or log line
What CRLF is, and why it matters
In an HTTP/1.1 message, each header sits on its own line, and an empty line separates the headers from the body. A server or client decides where one header ends and the next begins by looking for the line ending.
If an application copies input into a header, for example the target of a redirect, and the input contains a line ending, everything after it becomes a new header. The application meant to send one value; the attacker has written part of the response.
HTTP response splitting
With two line endings in a row, the attacker ends the headers and starts the body, or even a second response. That is HTTP response splitting. A cache in between may store the forged response under a legitimate address and serve it to other users, which turns one injection into a persistent attack.
Modern frameworks and servers refuse line breaks in header values, which has made response splitting rarer. It survives in hand-built headers, older components and proxies that rewrite requests. Proxies are also where HTTP request smuggling starts.
Host header injection
Host header injection needs no line break. The application trusts the Host header to build absolute links, for example in password reset emails, and the attacker sends a request with their own domain in it. The victim receives a genuine email whose reset link points to the attacker.
The fix is to build links from a configured site address, never from the request, and to answer only for host names the site expects.
What a WAF catches, and what it misses
Encoded line endings inside parameters that should be single-line values are a clear signal, and rule sets match them. Unexpected Host values can be refused at the edge if the list of valid names is known.
A filter misses line breaks that arrive in forms it does not decode, and values that become headers only after the application combines them. The safe behaviour has to be in the code that writes headers and logs.
How to prevent CRLF injection
- Use framework functions to set headers. They refuse values containing line breaks.
- Validate redirect targets. Allow only relative paths or listed hosts, which also prevents open redirects.
- Encode log entries. Replace line breaks so one request cannot write several log lines.
- Build absolute links from configuration. Never from the Host header of the request.
- Keep proxies and servers updated. Request and response parsing bugs are fixed there.
Questions
What is CRLF injection?
CRLF injection is an attack in which input containing carriage return and line feed characters reaches an HTTP header or log line, letting the attacker add headers, log entries or even a whole response.
What is HTTP response splitting?
HTTP response splitting uses CRLF injection to end a response's headers early and write the body or a second response, which a cache may then serve to other users.
What is host header injection?
Host header injection abuses an application that trusts the Host header to build links, so password reset or other emails contain links to the attacker's domain.
How do you prevent CRLF injection?
Set headers through framework functions that refuse line breaks, validate redirect targets, encode log entries, and build absolute links from configuration rather than from the request.