Exploiting HTTP Host Header: From Password Reset Poisoning to SSRF

This article explains the purpose of the HTTP Host header, how Host header attacks work, methods to discover and exploit them—including password‑reset poisoning, cache poisoning, access‑control bypass, and SSRF—and provides practical mitigation techniques for developers and security teams.

Programmer DD
Programmer DD
Programmer DD
Exploiting HTTP Host Header: From Password Reset Poisoning to SSRF

1. HTTP Host Header Attack

Since HTTP/1.1 the Host header is mandatory and specifies the domain the client wants to reach. Example request:

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

If a proxy forwards the request, the Host value may be altered before reaching the backend, leading to a Host header attack.

2. Role of the HTTP Host Header

The Host header helps the backend identify which application should handle the request. When missing or malformed, it can cause problems. Historically this was less of an issue because each IP served a single domain, but with virtual hosting and shared IPs it became critical.

Virtual hosting

Proxy‑routed traffic (load balancers, CDNs)

The Host header works like the apartment number on a letter, directing it to the correct recipient.

3. What Is an HTTP Host Header Attack

Some applications trust the Host header without validation. An attacker can inject a malicious Host value to manipulate server behavior, such as generating URLs for password‑reset emails.

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

Because the Host header is user‑controllable, it can be combined with other vulnerabilities like cache poisoning, logic flaws, SSRF, or SQL injection.

4. How to Discover HTTP Host Header Attacks

First, check whether the server validates the Host header. Then modify the Host value and observe the response. If the server reflects the modified value, it is vulnerable. Common techniques include:

Modify Host Value

Change the Host header and see if the payload appears in the response.

Add Duplicate Host Headers

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

One header may be used for routing, the other for payload delivery.

Use Absolute‑URL Requests

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

Add Indentation or Newlines

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

Inject via Similar Fields

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

Other fields such as X‑Host, X‑Forwarded‑Server, X‑HTTP‑Host‑Override, Forwarded can also be abused.

Ignore Port, Validate Only Domain

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

If the server ignores the port, the payload can be placed after the colon.

5. HTTP Host Header Attack Vulnerability Examples

5.1 Password‑Reset Poisoning

When a password‑reset link is generated using the Host header, an attacker can change the Host to a domain they control, stealing the reset token.

https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j

By modifying the Host to evil-user.net, the victim receives a link pointing to the attacker’s site, allowing token capture and password change.

5.2 Host Header + Cache Poisoning

If the site caches resources based on the Host header, an attacker can poison the cache with malicious JavaScript (e.g., alert(document.cookie);) that will be served to other users.

5.3 Host Header Bypass of Access Control

Changing the Host to an internal address can bypass IP‑based access restrictions, granting access to admin pages.

5.4 Host Header + SSRF

When the server uses the Host header to make internal requests, an attacker can direct those requests to internal services (e.g., 192.168.0.240) and retrieve sensitive data.

GET http://internal‑service/ HTTP/1.1
Host: 192.168.0.240

6. Mitigations for HTTP Host Header Attacks

Prefer relative URLs instead of relying on the Host header.

6.1 Properly Configure Absolute URLs

When absolute URLs are required, store the domain in configuration and do not derive it from the Host header.

6.2 Whitelist Validation

Validate the Host header against an allow‑list of known domains and reject or redirect unknown hosts.

6.3 Disable Header Overwrites

Ensure fields like X‑Forwarded‑Host are not trusted unless explicitly needed.

6.4 Separate Internal and Public Hosts

Do not host internal services on the same server as public applications to prevent Host header manipulation from reaching internal resources.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Web Securitycache poisoningSSRFHTTP Host headerpassword reset poisoning
Programmer DD
Written by

Programmer DD

A tinkering programmer and author of "Spring Cloud Microservices in Action"

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.