HTTP headers and log lines are structured by line breaks, the carriage-return and line-feed characters, and that structure is exactly what CRLF injection abuses. If your backend puts user input into an HTTP header, a redirect location, a cookie value, a custom header, or into a log line, without stripping those control characters, an attacker can embed a line break and inject content the parser treats as a new header, a new log entry, or even a response body. The consequences range from forged logs to response splitting and cache poisoning. Here is what CRLF and HTTP header injection are, where they lead, and how to prevent them on a mobile app's backend.
Short answer
CRLF injection is a vulnerability where untrusted input containing carriage-return and line-feed characters is placed into output that is structured by line breaks, such as HTTP headers or log entries, letting an attacker inject new lines. Per OWASP, in HTTP responses this becomes header injection or response splitting, where an attacker adds headers or splits the response, enabling effects like cache poisoning or injecting a body; in logs it becomes log forgery. It affects mobile backends that build response headers, redirects, or cookies, or log lines, from user input. The fix is to keep untrusted input out of headers, or strip and reject CR and LF and other control characters, validate values, and use framework APIs that handle header encoding rather than concatenating input into raw output.
What you should know
- CRLF injection abuses line-break structure: in headers and logs.
- In HTTP responses it splits or injects headers: response splitting.
- In logs it forges entries: fake or misleading log lines.
- It comes from input in headers or logs: a redirect, cookie, or logged value.
- The fix is to strip CR/LF and validate: and use safe framework APIs.
What is CRLF and HTTP header injection?
It is injecting line-break characters into output whose meaning depends on lines. HTTP headers are separated by carriage-return and line-feed sequences, and a blank line marks the end of the headers and the start of the body, so the structure is defined by these control characters. CRLF injection happens when untrusted input containing CR and LF is written into that structure without being neutralized: an attacker includes a line break in a value, and what follows is interpreted as a new header line, or, with two line breaks, as the start of the response body. In HTTP responses this is header injection, and the more dramatic form where the attacker effectively starts a new response is response splitting. The same idea applies to log files, where injecting line breaks into a logged value lets an attacker forge or inject log entries, called log injection. The root cause is identical to other injection flaws: untrusted input is placed into a structured output without separating data from the structure, here the structure being lines delimited by CR and LF.
Where does it lead?
To several effects, depending on where the injection lands. The table lists them.
| Target | Effect |
|---|---|
| Response headers | Injected headers change response behavior |
| Response splitting | A crafted body or second response is injected |
| Set-Cookie | An attacker sets or manipulates cookies |
| Redirect location | A header-based redirect manipulated |
| Log files | Forged or misleading log entries |
When user input reaches HTTP response headers, injecting a line break lets an attacker add headers of their own, which can change how the response is handled, and in the response-splitting case inject body content, which can lead to cache poisoning or content injection. Input flowing into a Set-Cookie header can let an attacker set or alter cookies, and input in a redirect's location header can be manipulated, which overlaps with redirect issues. In logging, CRLF injection lets an attacker insert fake log lines or break log parsing, undermining the integrity of your logs and any monitoring built on them. Modern servers and HTTP libraries increasingly reject CR and LF in header values, which blocks the classic response-splitting attack in many stacks, but custom code that builds headers or logs by hand can still be vulnerable, so the risk has not disappeared.
How do you prevent it?
Keep control characters out of structured output, and use safe APIs. The cleanest approach is to not place untrusted input into HTTP headers or log lines at all where you can avoid it. Where you must include user-influenced values, strip or reject carriage-return, line-feed, and other control characters before the value enters a header or log, so a line break in the input cannot create a new line in the output, and validate the value against what it should be, for example allowlisting a redirect destination rather than echoing an arbitrary one. Use your framework's APIs for setting headers and cookies, which generally encode or reject illegal characters, rather than building raw header strings by concatenation, and rely on a modern HTTP server and library that reject CR and LF in header values as defense in depth. For logging, encode or sanitize values before writing them, or use structured logging that does not let a value break the line structure, so logged input cannot forge entries. Apply this on the server, since the attacker supplies the input by calling your API directly. The principle, again, is to separate data from structure: a user-supplied value is data, and it must never be able to introduce the line breaks that define headers or log entries.
What to watch out for
The first trap is building HTTP headers, redirects, or cookies from user input by hand, where an injected line break creates new headers or splits the response; strip CR/LF, validate, and use framework APIs. The second is logging user input without sanitizing it, allowing forged log entries. The third is assuming your stack is immune because modern servers reject CRLF in headers, when custom header or log construction can still be vulnerable. CRLF injection is server-side, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, assesses the app's input handling and surfaces the endpoints it calls, while sanitizing headers and logs is yours to implement on the backend.
What to take away
- CRLF injection places line-break characters from untrusted input into line-structured output like HTTP headers or logs, letting an attacker inject new headers, split responses, or forge log entries.
- It affects mobile backends that build headers, redirects, cookies, or log lines from user input, with effects from cache poisoning to log forgery.
- Prevent it by keeping untrusted input out of headers and logs, stripping and rejecting CR/LF and control characters, validating values, and using framework APIs and structured logging instead of raw concatenation.
- CRLF injection is server-side; use a pre-submission scan such as PTKD.com to assess input handling, and sanitize header and log output on the backend.
