Cybersecurity glossary
What is HTTP Response Splitting?
Learn what HTTP response splitting is, how CRLF injection in headers creates extra HTTP responses, how it enables XSS and cache poisoning, and how it differs from response smuggling.
Definition
HTTP response splitting is an attack in which untrusted input injected into HTTP response headers introduces CRLF sequences that terminate the current response early and start a second attacker-controlled response, enabling XSS, session fixation, and cache poisoning.
Why HTTP response splitting matters
Servers do not only send HTML bodies. They emit status lines, headers, and cookies that browsers and caches parse as structured HTTP. If application code reflects user input into those headers without sanitizing line breaks, attackers can split one response into two—and control the second.
HTTP response splitting is a classic web vulnerability that predates modern frameworks but still appears in custom redirects, legacy CGI, and hand-built HTTP handlers.
How response splitting works
Find reflected header output
Locate parameters echoed into Location, Set-Cookie, or custom response headers.
Inject CRLF sequences
Insert %0d%0a (CRLF) to terminate the current header block and start new header lines.
Forge a second response
Add attacker-controlled status, headers, and body as if they were a complete HTTP response.
Browser or cache parses both
The client treats the stream as two responses; the forged one may be cached or executed.
Deliver impact
Victims receive poisoned HTML, malicious cookies, or script from a trusted URL.
Fix at the source
Stop reflecting untrusted data into headers; reject CR/LF in all header values.
Typical impacts
Cross-site scripting
A split response body containing script is served from a trusted domain or cached URL.
Session fixation
Injected Set-Cookie headers assign attacker-chosen session identifiers to victims.
Cache poisoning
Shared caches store the forged response and serve it to unrelated visitors.
Open redirect abuse
Split Location headers redirect users through attacker-controlled destinations.
Response splitting vs related attacks
| Term | Direction | Root cause |
|---|---|---|
| HTTP response splitting | Server → client | CRLF injection in response headers built by the application |
| HTTP response smuggling | Server → client | Proxy/client disagreement on response message boundaries |
| HTTP request splitting | Client → server | Multiple requests interpreted from one inbound stream |
| HTTP header injection | Either direction | Untrusted data inserts new header lines (splitting is a severe form) |
Prevention checklist
- Never concatenate untrusted input into raw HTTP response headers or status lines.
- Reject CR (%0d), LF (%0a), and NUL in any value used in Location, Set-Cookie, or custom headers.
- Use framework APIs (for example res.redirect, Set-Cookie helpers) that encode or validate header values.
- Validate redirect targets against an allowlist; do not reflect full URLs from query parameters.
- Send Cache-Control: no-store on dynamic responses that reflect user input in headers.
- Configure reverse proxies to reject responses with malformed header framing where supported.
- Test redirect, cookie, and custom header endpoints with CRLF payloads in authorized assessments.
- Prefer HTTP APIs and JSON responses over hand-crafted HTTP/1.1 message assembly.
Limits and pitfalls
Modern frameworks reduce raw header assembly, but edge cases remain: custom middleware, CGI scripts, error handlers that echo parameters, and reverse proxies that merge headers from multiple backends.
Response splitting is also not the same as MIME sniffing or XSS via HTML body—it attacks the HTTP framing layer. Defenses must target header output, not only HTML encoding in page templates.
The practical takeaway
HTTP response splitting forges extra HTTP responses by injecting line breaks into headers the server emits. One reflected parameter in a redirect or cookie can become stored XSS or cache poisoning for every visitor who hits the poisoned URL.
Treat every byte written to response headers as security-sensitive: reject CRLF, use safe APIs, and assume any unsanitized reflection into headers is a splitting vector waiting to be exploited.
Related security terms
HTTP Header Injection
The broader class of attacks that insert header lines via untrusted input.
HTTP Response Smuggling
Desync on response boundaries between intermediaries, distinct from CRLF injection in app output.
Cross-Site Scripting (XSS)
A common impact when split responses inject script into cached or rendered pages.
Web Cache Poisoning
Shared caches may store attacker-controlled split responses under victim URLs.
Frequently asked questions
What is HTTP response splitting in simple terms?
Response splitting tricks a browser or cache into seeing two HTTP responses where the server intended one. Attackers inject carriage return and line feed characters into headers so the first response ends early and a forged second response follows.
How is response splitting different from response smuggling?
Response splitting injects CRLF into response headers that the application builds—usually from reflected user input. Response smuggling exploits inconsistent response-boundary parsing between proxies and clients, similar to request smuggling but on the outbound path.
How is response splitting different from request splitting?
Request splitting affects inbound messages (client to server). Response splitting affects outbound messages (server to client). Request splitting can enable smuggling; response splitting forges what browsers and caches receive.
What can attackers achieve with response splitting?
Inject malicious HTML or JavaScript via poisoned caches, set attacker-controlled cookies, hijack sessions, or bypass content security controls when split responses are stored and served to other users.
Where do response splitting bugs appear?
Redirects, Set-Cookie, Location, custom headers, and any server-side code that reflects untrusted data into HTTP headers without stripping CR (%0d) and LF (%0a).
How do you prevent HTTP response splitting?
Never reflect untrusted input into raw HTTP headers, strip or reject CR/LF in header values, use framework APIs that encode headers safely, and validate redirects and cookies server-side.
References
Explore authoritative guidance and frameworks related to http response splitting.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.