Developers prevent HTTP Request/Response Splitting by rejecting or encoding carriage return and line feed characters in any value that reaches HTTP headers and by using safe framework APIs for header construction. If untrusted input can break header boundaries, attackers may inject extra requests or responses, so inspect redirects, cookies, and custom headers for unsafe concatenation.
How request and response splitting happens
HTTP request and response splitting is a boundary-breaking input problem. If application data is copied into an HTTP header without filtering carriage return and line feed characters, an attacker can terminate the intended header and start a new request or response. The risk is not limited to one feature, it can appear anywhere user-controlled data reaches header construction.
The core failure is trusting raw input in a context where line breaks are structural, not decorative. A value that looks harmless in a form field can become dangerous when it is later reused in a redirect location, a cookie, a cache directive, or any custom header. That is why the defense is about context-aware encoding and safe APIs, not just generic input validation.
Frameworks and libraries often help because they separate header names, values, and line handling instead of letting developers concatenate strings manually. When the framework does the encoding or rejects illegal characters for you, the application is much less likely to let an attacker turn one HTTP message into two.
Where developers need to inspect the code path
The highest-risk spots are the places where developers are tempted to pass through untrusted text unchanged. Redirect targets, cookie values, error messages, and dynamically built headers deserve special review because they often feel operational rather than security-sensitive. In practice, the bug usually appears in a helper function or shared utility, then spreads across multiple endpoints.
It also matters to look at downstream transformations. Sanitising a value after it has already been folded into a header string is too late, because the parser may already have interpreted the boundary. The safest pattern is to reject or encode control characters before header construction, and to use APIs that treat the header as structured data from the start.
For teams that want a broader map of how header-level injection fits into web attack patterns, the Web Application Attacks Guide covers request smuggling, response splitting, redirects, and related injection paths in one place.
Why safe defaults and tests matter
A security review should treat this as both an application bug and a library-usage bug. If the codebase has custom header builders, wrapper classes, or old redirect utilities, those are prime candidates for regression. Tests should prove that carriage return and line feed characters are rejected or neutralised, and that header output cannot be altered by embedded line breaks.
Developers should also check any place where header values are composed from multiple parts. One unsafe concatenation anywhere in the chain can reintroduce the issue even if the main request handling is otherwise clean. The goal is to make the safe path the easy path, so the code does not depend on every caller remembering the same low-level rules.
Risk and Threat Considerations
When this flaw exists, the attacker is not trying to break cryptography or guess credentials, they are trying to exploit HTTP parsing itself. A successful split can enable cache poisoning, response injection, cookie manipulation, or request smuggling-style follow-on abuse, depending on where the malformed header lands.
Failure mechanism: Untrusted input reaches an HTTP header sink without CRLF filtering or structured encoding, allowing the attacker to inject a second message boundary.
Impact: The server, browser, proxy, or intermediary may process extra headers or an extra request or response, creating exposure ranging from session tampering to downstream request confusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Header handling often affects redirect and token flow safety. |
| V13 — Configuration | Safe framework configuration governs whether headers are encoded or rejected. | |
| V16 — Security Logging and Error Handling | Malformed header input and split attempts should be observable and testable. | |
| Recommendation — Use structured redirect and header handling to prevent injection into auth flows. Enable secure defaults that reject control characters in header values. Log rejected header-control input and alert on repeated boundary-breaking attempts. | ||
Practitioner Guidance
What to verify: Confirm that every code path that writes headers, redirects, or cookies uses framework-safe APIs or rejects CR and LF before concatenation. Pay extra attention to shared helpers, because a single unsafe utility can affect many routes.
Common mistake: Teams often validate the visible form field but forget that the same value may be reused later in a different context. A value that is safe in a database field can still be unsafe when reused in an HTTP header.
Practitioner takeaway: Treat header generation as a structured operation, not a string-building exercise, and verify the boundary at the last possible point before the HTTP message is emitted.