Prevent CRLF injection by encoding all user input before it enters HTTP headers or response bodies. Use strict output encoding libraries rather than manual string replacement. Validate input against a whitelist of allowed characters. Implement Content Security Policy headers to mitigate residual risks. Never trust raw user data in URL redirects or cookie values.
Why CRLF Injection Bypasses Standard Defences
Carriage Return Line Feed injection exploits the way web servers and browsers parse HTTP protocol structures. The HTTP specification uses specific control characters to separate headers from the response body. An attacker inserts these control characters into user-supplied data. The server treats the injected data as part of the protocol structure rather than content. This breaks the boundary between header and body. The browser then executes instructions from the injected section.
This mechanism allows an attacker to inject arbitrary HTTP headers. Those headers can include scripts or redirect directives. The attack succeeds because the application fails to distinguish between data and code. Standard input validation often misses this because it checks for script tags, not protocol delimiters. The vulnerability exists in how the application constructs HTTP responses. It is not a flaw in the browser alone. The server must encode or reject the dangerous characters before sending the response.
The Hidden Cost of Manual Input Sanitisation
Many developers attempt to stop CRLF injection by removing carriage return and line feed characters from user input. This approach is fragile and often fails. Attackers use various encoding schemes to hide these characters. They might use URL encoding, HTML entities, or Unicode escapes. A simple string replacement function only catches literal characters. It does not catch encoded variants. This creates a false sense of security. The application appears secure during basic testing.
It fails when faced with sophisticated payloads. Maintaining a blacklist of forbidden characters is unsustainable. New encoding methods emerge regularly. The maintenance burden increases over time. You spend more time updating filters than building features. This hidden cost drains development resources. It also increases the likelihood of human error. A missed encoding variant leaves the system vulnerable. The trade-off between ease of implementation and security effectiveness is poor here.
| Measure | Effort | What it stops |
|---|---|---|
| Output Encoding | Low | Prevents interpretation of control characters as headers |
| Input Whitelisting | Medium | Blocks unexpected characters before processing |
| HTTP Header Validation | Low | Ensures headers conform to expected format |
| Content Security Policy | Medium | Mitigates impact of successful injection |
| Manual String Replacement | Low | Stops only literal CRLF sequences |
Priority One: Strict Output Encoding
Output encoding is the most reliable defence against CRLF injection. You must encode data at the point where it enters a new context. If user data goes into an HTTP header, encode it for HTTP headers. If it goes into the response body, encode it for HTML. This ensures the data is treated as literal text. It prevents the parser from interpreting control characters as structural elements. Use established libraries for this task. Do not write custom encoding functions.
Custom functions often miss edge cases. They may fail to handle specific character sets correctly. The library handles the complexity of different encoding standards. It updates automatically with security patches. You focus on your application logic. The library handles the security mechanics. This separation of concerns reduces risk. It also simplifies code reviews. Reviewers can trust the library. They do not need to audit every encoding line. This approach scales with your application growth.
Priority Two: Input Whitelisting
Input whitelisting complements output encoding by restricting data at the source. Define exactly what characters are allowed in each input field. Allow only alphanumeric characters for usernames. Allow only digits for phone numbers. Reject any input that contains characters outside this list. This prevents malicious data from entering your system. It reduces the attack surface significantly. Whitelisting is more secure than blacklisting.
Blacklisting requires knowing every possible attack vector. Whitelisting only requires knowing what is valid. This is a manageable task for most applications. It forces clear data design. You must define data types explicitly. This improves data quality overall. It also simplifies debugging. Invalid data is caught early. You do not waste time tracing corrupted data through the system. The effort is upfront. The benefit is long-term security stability.
Priority Three: HTTP Header Validation
Validate all HTTP headers before processing them. Ensure that headers conform to the expected format. Reject headers that contain unexpected characters or structures. This protects your application from malformed requests. It also prevents attackers from injecting headers via CRLF sequences. Many web frameworks provide built-in validation. Use these features. Do not disable them for convenience. Custom validation logic is prone to errors.
It may miss subtle variations in attack patterns. The framework validators are tested extensively. They handle edge cases you might not consider. This measure adds a layer of defence in depth. It works alongside encoding and whitelisting. It catches attacks that slip through other layers. It is a low-effort, high-reward measure. Implement it early in your request processing pipeline. Reject bad requests before they reach your business logic.
See also: API Abuse Prevention Checklist: Stop Data Leaks and Logic Flaws
What Does Not Work: The Myth of Complete Protection
No single measure stops all CRLF injection attempts. You must assume that some attacks will bypass your defences. This is why defence in depth is necessary. Do not trust client-side validation. Attackers can bypass it easily. They can craft requests directly to your server. Do not rely on web application firewalls alone. They may have false negatives. They might not recognise novel attack patterns. You must implement server-side controls.
These controls are harder to bypass. They run on your infrastructure. You control their configuration. This gives you greater assurance. However, even server-side controls are not perfect. They require regular updating. They need proper configuration. Neglecting maintenance undermines their effectiveness. Treat security as a continuous process. It is not a one-time fix. Regular review and testing are required.
Mitigating Impact with Content Security Policy
Content Security Policy provides a safety net when injection occurs. It restricts where scripts can load from. It prevents inline scripts from executing. This limits the damage an attacker can do. Even if they inject a script, the browser may block it. This reduces the likelihood of successful exploitation. CSP is an additional layer of defence. It does not prevent injection. It mitigates the impact. Implement CSP headers in your responses.
Define strict policies. Allow only trusted sources. This measure is particularly effective against cross-site scripting. It complements CRLF prevention. It addresses the downstream effects of header injection. The effort to implement CSP is moderate. The benefit is significant risk reduction. It is a standardised approach. Browsers support it widely. Use it to harden your application against residual risks.
Three Actions to Take Today
- Audit your input handling functions. Check for manual string replacement of control characters. Replace them with library-based output encoding.
- Implement input whitelisting for all user-facing fields. Define allowed character sets explicitly. Reject any input that falls outside these sets.
- Add Content Security Policy headers to your HTTP responses. Configure them to block inline scripts and untrusted sources.
Key takeaways
- Output encoding is more effective than input validation for stopping header injection attacks.
- CRLF injection can bypass same-origin policy controls by splitting HTTP responses.
- Manual string replacement of carriage returns often fails against encoded or polyglot payloads.
CRLF injection exploits protocol parsing boundaries, requiring strict output encoding and input whitelisting to prevent. Implement these measures immediately to stop attackers from injecting malicious HTTP headers into your responses.
Frequently asked questions
Does HTTPS prevent CRLF injection?
No, HTTPS encrypts data in transit but does not validate or encode the content. Attackers can still send malicious payloads over encrypted connections. You must encode data regardless of the transport protocol.
Can a Web Application Firewall stop all CRLF attacks?
No, WAFs can block known patterns but may miss novel or encoded attacks. They should be used as an additional layer, not the sole defence. Server-side encoding and validation are still required.
How this guide was produced: written by the RedTeam Log editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
