CRLF Injection
detect, understand, remediate
CRLF injection inserts carriage return and line feed characters into HTTP responses, allowing attackers to split responses, inject headers, set malicious cookies, or enable cross-site scripting.
No credit card required. Free plan available forever.
What is CRLF injection?
CRLF injection, also known as HTTP response splitting, is a web security vulnerability that occurs when an attacker injects carriage return (\r) and line feed (\n) characters into HTTP response headers. These two characters (CR and LF, represented as %0d%0a in URL encoding) serve as the delimiter between HTTP headers and between the headers and body sections. By injecting these characters into user-controlled input that is reflected in response headers, an attacker can manipulate the structure of the HTTP response itself. This vulnerability is classified as CWE-93 and falls under the broader category of injection attacks.
The consequences of CRLF injection range from session hijacking to cross-site scripting (XSS). An attacker can inject arbitrary HTTP headers, such as Set-Cookie to fixate sessions, or inject an entirely new response body containing malicious JavaScript. When chained with open redirect vulnerabilities, CRLF injection can be used to craft sophisticated phishing attacks that appear to originate from trusted domains.
CRLF injection vulnerabilities are particularly common in applications that reflect user input in HTTP response headers without sanitisation. Redirect endpoints, cookie-setting mechanisms, and logging functions are frequently affected. While modern web frameworks generally protect against basic CRLF injection, custom header manipulation code, legacy applications, and API gateways remain vulnerable, especially when developers bypass framework-level protections for performance or flexibility.
How it works
Identify reflected input in headers
The attacker finds an input (URL parameter, cookie value, or form field) that is reflected in an HTTP response header such as Location, Set-Cookie, or a custom header.
Inject CRLF characters
The attacker appends %0d%0a (URL-encoded \r\n) to the input, followed by a crafted header or a blank line to begin a new response body section.
Split the HTTP response
The server includes the injected characters in the response, effectively splitting it into two separate HTTP responses or injecting new headers into the existing response.
Inject headers or body content
The attacker injects malicious Set-Cookie headers to fixate sessions, adds XSS payloads via an injected response body, or poisons cached content served to other users.
Common causes
User input in Set-Cookie values
Applications that embed user-supplied data directly into Set-Cookie response headers without stripping newline characters, enabling attackers to inject additional cookies or headers.
Location header redirect URLs
Redirect endpoints that construct Location header values from user-controlled parameters (such as return URLs) without encoding or validating for CRLF sequences.
Custom response headers
Applications that set custom response headers based on user input (for example, content-disposition filenames or custom tracking headers) without sanitising newline characters.
Log file entries
Logging mechanisms that write user-controlled data to log files without encoding CRLF characters, allowing attackers to forge log entries or inject malicious content into log analysis tools.
How to detect it
Automated detection
- SecPortal's authenticated scanner injects encoded CRLF sequences into all discovered parameters and detects when injected headers appear in server responses
- Response header analysis detects user-controlled values reflected in Set-Cookie, Location, and custom headers without proper encoding
- Code scanning identifies patterns where raw user input is concatenated into response header values without sanitisation functions
Manual testing
- Append %0d%0aInjected-Header:test to URL parameters and inspect raw response headers for the injected header using a proxy tool
- Test redirect endpoints by injecting CRLF sequences followed by a Set-Cookie header to verify if session fixation is possible
- Try different encoding variations (double URL encoding, Unicode, null bytes) to bypass input filters that only check for literal \\r\\n characters
How to fix it
Strip or encode \r\n from all header values
Before setting any HTTP response header, remove or URL-encode all carriage return (\r) and line feed (\n) characters from user-supplied input. This prevents attackers from injecting new headers or splitting the response.
Use framework-provided header methods
Always use your web framework's built-in response header APIs (e.g. response.setHeader(), res.redirect()) rather than manually constructing raw HTTP responses. Framework methods typically include built-in CRLF protection.
Validate redirect URLs
When constructing Location headers for redirects, validate that the destination URL matches an allow-list of permitted domains and does not contain encoded newline characters or other injection sequences.
Apply output encoding consistently
Implement a centralized output encoding layer that sanitises all user-controlled data before it is included in HTTP headers, response bodies, or log files. Use context-appropriate encoding for each output channel.
Deploy HTTP response header monitoring
Monitor outgoing HTTP responses for unexpected headers (especially Set-Cookie headers not set by your application) and anomalous response structures that may indicate successful CRLF injection exploitation.
Compliance impact
Related vulnerabilities
Detect CRLF injection vulnerabilities
SecPortal tests for header injection, response splitting, and encoded CRLF bypass techniques. Start free.
No credit card required. Free plan available forever.