What causes HTTP request and response splitting?

HTTP request and response splitting happens when untrusted input reaches HTTP header construction without proper sanitisation, so an attacker can inject CRLF characters and create extra headers or body content. Defenders should block control characters, validate header values strictly, and review any code that reflects user input into requests, redirects, caches, or responses.

How HTTP request and response splitting starts

The core condition is simple: application data is inserted into an HTTP header or status line without strict validation, and that data still contains carriage return and line feed characters. Once those control characters are accepted, the attacker can terminate the current header and begin a new one, which changes how the server, proxy, cache, or browser interprets the message.

This is usually not a single bug in the protocol itself. It is a failure in input handling, output encoding, or both. The risk increases when code builds headers from user-controlled values such as filenames, redirect targets, cookies, reflected parameters, or forwarded request metadata, because those fields are often treated as safe text when they are not.

One useful way to think about the issue is that HTTP parsing is strict, but application code often is not. If the application normalises input too late, or assumes framework helpers will always neutralise control characters, the attacker gets a chance to reshape the message before it leaves the application boundary.

Where the injection becomes exploitable

Request and response splitting only become visible when the injected line break is interpreted by an HTTP component that trusts the malformed message. That component may be an origin server, reverse proxy, cache, load balancer, or downstream client. The exact impact depends on which hop accepts the crafted header and how the next hop processes the resulting message.

In response splitting, the attacker tries to force the server to emit a second response or to modify headers such as Location, Set-Cookie, or Content-Type. In request splitting, the attacker tries to smuggle an extra request through an intermediary or influence how a downstream server parses request boundaries. The practical concern is not the syntax alone, but whether the malformed output crosses a trust boundary and changes server-side behaviour.

The Web Application Attacks Guide is the best starting point when you want to place HTTP request and response splitting in the wider family of injection and message-parsing flaws.

What to fix first in code and architecture

Defensive work should start with every place where untrusted input can reach HTTP construction, especially header values, redirect logic, and any code that reflects request data into responses. The safest pattern is to reject control characters outright, apply allowlist validation for header-safe values, and use framework or library APIs that encode headers correctly rather than concatenating strings by hand.

Pay particular attention to shared components such as caches and proxies, because a single malformed response can be reused more broadly than the original request. If a code path writes to multiple HTTP layers, validate at the earliest boundary and re-check at the point of emission. The goal is to make it impossible for a hostile payload to survive long enough to reach a parser that will treat it as a delimiter.

Review redirects, download handlers, filename reflections, error pages, and header echo features first, because those are the places where developers most often reuse user input in structurally sensitive parts of the response. If sanitisation is inconsistent across services, treat the weakest component as the real exposure, not the strongest one.

Risk and Threat Considerations

HTTP request and response splitting can create cache poisoning, header injection, session manipulation, open redirect chaining, and in some environments full response body manipulation. The security issue is not just malformed traffic, it is that one injected delimiter can change what other systems believe the message contains.

Failure mechanism: An attacker supplies CRLF characters in data that is later embedded in an HTTP header or status block, and the parser interprets the injected line break as the start of a new header or message section.

Impact: The attacker may add, alter, or truncate headers and content, poison shared caches, control redirects, or influence downstream clients and intermediaries that trust the rewritten response.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V12 — Secure Communication	HTTP splitting exploits unsafe message construction across HTTP boundaries.
	V15 — Secure Coding and Architecture	The flaw arises from insecure string concatenation and unsafe output handling.
Recommendation — Enforce strict header encoding and reject CRLF in all HTTP output paths. Centralize HTTP serialization and remove ad hoc header building from application code.
CIS Controls v8	CIS-16 — Application Software Security	The issue is a web application input-handling flaw that needs secure coding review.
Recommendation — Review application code for unsafe reflection of user input into HTTP responses.

Practitioner Guidance

What to verify: Check every header-writing path, including framework helpers, custom middleware, and error handling, to confirm they reject control characters before any HTTP serialization occurs. Also verify that sanitisation is applied to the actual emitted value, not just to a copied upstream field.

Common mistake: Relying on generic HTML escaping or input trimming is not enough, because HTTP splitting is caused by message structure, not by markup. Another frequent mistake is fixing the obvious response path while leaving redirects, cache keys, or debug headers untouched.

Practitioner takeaway: Treat every user-influenced HTTP header as a parsing boundary, and design so that untrusted data can never become protocol syntax.