CRLF Injection
Table of Contents
Quick Answer
CRLF injection happens when carriage return and line feed characters are accepted in unsafe input and then interpreted inside HTTP headers, logs, redirects, or email headers. The safest defense is to reject or encode CRLF characters where they are not expected and to use framework-safe APIs for headers, redirects, logs, and email generation.
This defensive guide explains CRLF injection meaning, why line-break characters can create security risk, where the issue commonly appears, and how validation, output encoding, structured logging, and safe framework APIs reduce risk.
What is CRLF Injection?
CRLF injection is an input-handling weakness where an application accepts carriage return and line feed characters from untrusted input and later writes that input into a line-based context. The issue appears when those line breaks are treated as control characters instead of normal text.
Depending on where the unsafe value is used, CRLF injection can affect HTTP headers, redirects, log records, email headers, or other formats where a new line changes meaning. This page keeps examples conceptual and focuses on safe review and prevention.
CRLF Characters Overview
Carriage Return (CR)
Carriage return is commonly represented as \r. It returns the cursor to the beginning of a line in many text formats.
Line Feed (LF)
Line feed is commonly represented as \n. It moves to the next line in many text formats.
CRLF
Together, \r\n marks a line ending in several protocols and file formats. Because line endings can separate headers, records, or fields, CR and LF should be treated carefully when they come from user-controlled input.
How CRLF Injection Risk Happens
CRLF injection risk appears when an application accepts line-break characters from untrusted input and later places that input into a context where line breaks have special meaning, such as HTTP headers, redirects, logs, or email headers. The defensive goal is to treat CR and LF as control characters, not ordinary text, in those contexts.
| Step | Defensive view |
|---|---|
| Input is received | A header value, redirect target, email field, or log value includes user-controlled text. |
| Line breaks are not rejected | Control characters reach a line-based context. |
| Context interprets them | The receiving format treats the line break as a boundary between fields, headers, or records. |
| Control is applied | Validation, encoding, safe APIs, and structured output prevent unsafe interpretation. |
Where CRLF Injection Can Appear
| Context | What can go wrong | Safer defensive approach |
|---|---|---|
| HTTP headers | Untrusted line breaks may change header boundaries. | Reject CR/LF in header values and use framework header APIs. |
| Redirects | Unsafe input may affect redirect behavior. | Validate destinations and use allowlisted redirects. |
| Logs | Injected line breaks may confuse audit trails. | Encode or structure log fields safely. |
| Email headers | Header fields may be altered if unsafe input is trusted. | Use mail libraries and validate address/header fields. |
CRLF Injection Prevention Checklist
- Reject or normalize CR and LF characters where line breaks are not expected.
- Use framework APIs for headers, cookies, redirects, logs, and emails.
- Validate redirect destinations with allowlists.
- Encode values before writing to logs or text-based outputs.
- Prefer structured logging formats over plain concatenated log lines.
- Avoid passing raw user input into response headers or email headers.
- Review related protections such as security headers and input validation.
- Add tests for header, redirect, log, and email contexts in authorized development or QA environments.
Safe Developer Review Questions
- Can this input reach a response header, redirect, email header, or log line?
- Does the framework already reject CR/LF in this context?
- Are redirects restricted to known safe destinations?
- Are logs structured so one user-controlled value cannot create fake entries?
- Are validation failures handled safely without reflecting unsafe input?
FAQs
Sources and further reading
- OWASP - HTTP Response Splitting — CRLF and response-splitting background
- OWASP Cheat Sheet Series - Input Validation — Input validation controls
- CWE-93 - Improper Neutralization of CRLF Sequences — CRLF weakness reference