CRLF Injection Prevention Checklist for Secure HTTP Headers

Understanding the Protocol Boundary

CRLF injection attacks exploit how web servers parse HTTP responses. The HTTP protocol uses a carriage return followed by a line feed to separate headers from the message body. An attacker who can insert these two characters into a header value breaks that boundary. The server interprets the injected line as a new header or starts the body prematurely. This allows the attacker to dictate the structure of the response.

The danger lies in what happens after the break. An attacker can inject a Set-Cookie header to hijack sessions. They can inject a Content-Type header to force browser rendering changes. They can inject an HTML fragment that the browser executes as part of your page. This is distinct from cross-site scripting because the code comes from your own server, not an external source. The browser trusts your domain implicitly.

Server-Side Configuration Hardening

Web servers must reject malformed requests before they reach application logic. Most modern servers have built-in protections against header splitting. You must ensure these protections are active and not disabled for legacy compatibility. Review your server configuration files for any directives that allow loose parsing. Disable any module that permits raw header manipulation without sanitization.

• Enable strict header parsing: The server rejects requests with control characters in URI or headers.
• Disable header manipulation modules: Modules that allow dynamic header creation often bypass validation.
• Verify request smuggling protections: Improper parsing can lead to request smuggling, a related vulnerability.
• Restrict allowed HTTP methods: Limit methods to only those your application explicitly uses.

Input Validation Strategies

Application code must validate all user-supplied data. This includes data from query strings, POST bodies, cookies, and URL parameters. The validation must occur before the data is used in any string concatenation for headers. You must check for the specific byte values of carriage return and line feed. Checking for the literal string "\r\n" is insufficient because an attacker can send the raw bytes.

• Reject carriage return bytes: Block the 0x0D byte in all input fields.
• Reject line feed bytes: Block the 0x0A byte in all input fields.
• Use allowlists for input: Accept only expected characters like alphanumeric values and common punctuation.

Imagine a login form that accepts a username. If you use that username in a redirect header without checking for control characters, an attacker can inject a new header. The browser sees the injected header as part of the legitimate response. This leads to cache poisoning where malicious content is stored for all users.

Output Encoding and Header Safety

When your application constructs HTTP headers, you must encode the output. If user data must appear in a header, you must ensure it cannot contain control characters. Use a library that performs strict encoding. Do not rely on manual string replacement. Manual replacement often misses edge cases or double-encoding issues. The goal is to ensure the header remains a single line of text.

• Use safe header construction: Libraries that validate and encode header values automatically.
• Avoid dynamic header names: Never allow user input to define the name of a header.
• Validate response headers: Check generated headers before sending them to the client.
• Implement canonicalization checks: Normalize input to catch variations of CRLF sequences.

This approach complements other security measures. For example, proper handling of input prevents many forms of injection, similar to how you would prevent SQL injection. The principle is the same: never trust external data. You must treat all input as potentially malicious until it is proven safe through strict validation and encoding.

Testing and Verification

You must verify that your protections work. Static analysis tools can find potential injection points in your code. Dynamic testing tools can send crafted requests to your live environment. Penetration testing services can provide a deeper review of your application’s security posture. These tests should include attempts to inject CRLF sequences in various locations.

• Run static analysis scans: Identify code locations where user input flows to headers.
• Perform dynamic testing: Send requests with CRLF characters to test server rejection.
• Review error messages: Ensure errors do not leak information about the injection attempt.
• Monitor for anomalies: Watch for unexpected header values or response structures.

CRLF injection is a persistent threat because it targets the protocol itself. Even if you use memory-safe programming languages, the application logic can still be flawed. You must address the issue at every layer. Server configuration, input validation, and output encoding all play a role. Neglecting any one layer leaves you vulnerable.

See also: SQL Injection Warning Signs: Detecting Data Breaches Early

Integration with Broader Security

CRLF injection prevention works best as part of a larger strategy. You should integrate these checks into your development pipeline. Code reviews should specifically look for header manipulation. Security training should cover the mechanics of header splitting. This ensures that new developers understand the risk.

• Update security training: Include CRLF injection in developer onboarding materials.
• Review third-party components: Ensure libraries you use do not introduce vulnerabilities.
• Monitor for new variants: Keep up with changes in HTTP standards and parsing rules.
• Document validation rules: Create clear guidelines for handling user input in headers.

This aligns with broader practices like attack surface management. Reducing the number of places where user input touches headers reduces risk. It also complements the use of web application firewalls, which can block malicious patterns. However, you cannot rely solely on perimeter defenses. Application-level controls are necessary because attackers can bypass network filters.

Key takeaways

• CRLF injection exploits the protocol boundary between headers and body.
• Server configuration must block control characters at the network edge.
• Input validation must reject bytes, not just visible strings.

Frequently asked questions

Does CRLF injection work on HTTPS connections?

Yes, CRLF injection targets the HTTP protocol itself, which is encrypted by HTTPS. The encryption hides the attack from network monitors, but the server still parses the injected characters.

Can a web application firewall stop CRLF injection?

A properly configured web application firewall can block requests containing CRLF sequences. However, it is not a substitute for application-level input validation and server configuration.

Is CRLF injection the same as cross-site scripting?

No, CRLF injection manipulates HTTP headers and response structure. Cross-site scripting injects executable scripts into web pages. CRLF can lead to XSS, but the mechanisms are distinct.

How do I check if my application is vulnerable?

Send a request with a URL-encoded carriage return and line feed to a parameter that influences headers. If the server accepts it and includes it in the response, you are vulnerable.

How this guide was produced: written by the RedTeam Monitor 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.