HTTP Request Header Injection

How HTTP Request Header Injection Works

HTTP Request Header Injection happens when untrusted input is copied into an HTTP header without proper validation or encoding. The flaw can alter request handling or response generation, so a seemingly small injection point can change routing, caching, redirection, or how downstream intermediaries interpret the message.

It matters because headers sit inside a protocol that is parsed by browsers, reverse proxies, application servers and cache layers, and those components do not always treat malformed or unexpected values the same way. When an attacker can influence a header boundary, the effect may extend beyond the application code that first accepted the input.

Why It Becomes Dangerous

The main danger is that injected header content can change the meaning of a request or response in ways the application never intended. That can lead to response splitting, cache poisoning, open redirect behaviour, host or origin confusion, or proxy-level misrouting when intermediaries trust the modified header value.

In practice, the problem often appears where applications reflect user-controlled values into headers such as Location, Set-Cookie, X-Forwarded-* or custom routing headers. Once the header is accepted by another layer, the attacker may be able to influence what other users see, where traffic is sent, or which trust decisions are made downstream.

NHIMG’s Host Header Attacks and Validation Guide is useful here because many header injection failures overlap with host validation, proxy trust, and reset-link poisoning problems.

Where Organisations Should Check Exposure

Exposure usually starts with inventory: find every place the application copies request data into response headers, proxy headers, redirect targets, or cache-sensitive metadata. Testing should include direct requests, chained proxies, CDN layers, load balancers and any code paths that behave differently when a header is missing, duplicated or unusually formatted.

The most useful checks are whether the application trusts client-supplied header names or values, whether it normalises line breaks and control characters, and whether intermediaries rewrite or preserve headers in surprising ways. Header injection is especially important to review in apps that rely on reverse proxies, shared caches or framework-level host and forwarding settings.

NHIMG’s HTTP Request Smuggling Guide helps explain why proxy and server disagreement can turn malformed traffic into security impact beyond the original application layer.

Remediation and Compensating Controls

The core fix is to stop treating user input as header syntax. Applications should use allowlists, strict canonicalisation and framework-safe APIs for header construction, and they should reject control characters, CRLF sequences and other input that can change header structure.

Where patching or refactoring is not immediate, reduce blast radius with defensive proxy behaviour, cache hardening, and tight validation on host, forwarding and redirect headers. If the application does not need to accept client-controlled header values at all, remove that path rather than trying to sanitise every possible variant.

NHIMG’s Security Headers Guide is a useful companion because many header-injection failures become less exploitable when response headers and browser-facing controls are consistently hardened.

Detection and Post-Incident Review

Detection is usually a mix of malformed-request testing, log review and behavioural checks. Watch for unexpected header delimiters, duplicate headers, unusual redirect destinations, cache anomalies and proxy traces that do not match the application’s intended response path.

If exploitation is suspected, review whether any poisoned cache entries, altered redirects or attacker-influenced response headers were served to other users. Even after the injection point is closed, downstream artefacts such as cached responses, remembered redirects or tampered intermediary state may need to be cleared or revalidated.

For adjacent web-layer injection patterns, NHIMG’s Web Application Attacks Guide provides broader context on how request parsing flaws, response manipulation and injection chains are typically analysed.

Risk and Threat Considerations

HTTP request header injection can expose users to cache poisoning, redirect abuse and proxy confusion, especially when the injected value is consumed by shared infrastructure rather than only by the originating application. The risk increases when headers influence authentication flows, host resolution or cache keys.

Failure mechanism: Untrusted input becomes part of protocol metadata, and another component interprets it as a legitimate header or routing signal. That mismatch between application intent and intermediary parsing is what creates exploitable behaviour.

Impact: Attackers may alter responses for other users, manipulate navigation, bypass trust assumptions in proxies or caches, and in some cases assist follow-on attacks such as phishing or session abuse.

Practitioner Guidance

What to watch for: Prioritise code paths that reflect request data into headers, especially redirects, forwarding metadata and cache-influencing fields. Header handling should be reviewed at the application boundary and again at the proxy or CDN boundary, because either layer can turn a safe-looking implementation into an exploitable one.

Governance implication: Treat header construction as a security-sensitive coding pattern, not a formatting detail. Ownership should sit with the teams that control response generation, proxy configuration and caching behaviour, because the weakness often spans more than one service.

Related resources from NHI Mgmt Group

• What breaks when HTTP header injection is allowed to reach request boundaries?
• Why does HTTP header injection create a broader account takeover risk than a simple response manipulation issue?
• HTTP Response Header Injection
• HTTP Header Injection