HTTP Request/Response Splitting

How HTTP Request/Response Splitting Works

HTTP request/response splitting happens when unsanitised input reaches an HTTP header or response boundary and injects carriage return and line feed characters. That can make one message look like two, or let attacker-controlled content alter how downstream components parse the exchange.

The weakness is especially dangerous because it targets the protocol structure itself, not just page content. When a proxy, cache, application server, or browser interprets the injected boundaries differently, the result can be cache poisoning, response tampering, or request smuggling-like behaviour.

Where the Security Boundary Breaks Down

The core failure is trust in data that should never be allowed to influence framing. If header values, redirect targets, cookie attributes, or other response fields are built from user input without strict validation, the application may accidentally create a second header block or response body.

Web Application Attacks Guide covers this weakness alongside related injection and cache-poisoning patterns, which is useful because the practical impact often depends on how the target stack normalises special characters and intermediaries process the resulting traffic.

The issue is not limited to one layer. A front-end proxy, origin server, and browser can all disagree about where a message ends, so a payload that looks harmless to one component may still alter behaviour somewhere else in the chain.

Why It Matters for Web Security

Once message boundaries can be influenced, attackers may be able to inject headers, split responses, poison shared caches, or set up follow-on attacks such as script injection, content confusion, or session-related manipulation. The danger grows when the affected response is cached or reused across users.

Because the weakness sits in a protocol parsing path, impact is often broader than a single page or parameter. A successful exploit can undermine integrity for downstream clients and intermediaries even when the original application logic appears simple.

For related web attack context, the OWASP API Security Top 10 is a useful companion reference when response construction or API gateways are part of the exposure path.

Defensive Controls and Safe Handling

Prevention depends on treating header construction as a security-sensitive operation. Applications should reject or encode control characters, use framework APIs that safely build headers and responses, and avoid concatenating raw user input into any field that influences HTTP framing.

Where the response path includes reverse proxies, load balancers, or caches, defenders should test the full request chain rather than only the application code. Safe handling also means checking template helpers, redirect utilities, and error handlers, since these are common places where boundary data is assembled.

NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control baseline for input validation, secure coding, and boundary protection, while the OWASP API Security Top 10 helps teams think about similar boundary failures in service interfaces.

Risk and Threat Considerations

This weakness is dangerous because it can turn a simple input flaw into a trust-boundary failure across caches, proxies, and browsers. In the worst case, one attacker-controlled response can affect what other users receive or what downstream systems store.

Failure mechanism: Unsanitised carriage return and line feed characters survive into header or response construction, causing the HTTP parser to split or reinterpret the message boundary.

Impact: The attacker may poison caches, inject malicious headers, alter response content, or create a platform for secondary attacks that rely on confused request or response handling.

Practitioner Guidance

What to watch for: Review every place where application data becomes part of a header, redirect, cookie, or error response. Pay special attention to code paths that feel “internal” or low risk, because these often bypass the same scrutiny as user-facing forms.

Practitioner note: Testing should include the full delivery path, not just the origin application. A payload that is blocked by one layer but reinterpreted by another still represents a security defect.

Related resources from NHI Mgmt Group

• Why does HTTP request splitting create such serious risk for backend services and other users?
• CVE-2026-48710 (Kludex Starlette HTTP Request/Response Smuggling)
• What is the difference between SAML request signing and response encryption?
• Should organisations log every LLM request and response?