Host Header Injection Explained Simply

Host Header Injection is a web security vulnerability that happens when an application trusts the Host header coming from the user without validating it.
An attacker can manipulate this value and trick the application into believing it is running on a completely different domain.
And that can lead to some very serious attacks.

What Is the Host Header? 🧠​

When your browser sends a request to a server, it includes an HTTP header called Host.
Example:

GET / HTTP/1.1
Host: www.example.com

This tells the server: “I want the website hosted at www.example.com”
This exists because a single server IP can host multiple websites.

---

Where Does The Problem Start? ⚠️​

The issue appears when a server or application blindly trusts the Host value.
An attacker can simply change it.
Instead of:
Host: www.example.com
they send: Host: www.attacker.com
If the application is vulnerable, it may treat attacker.com as if it were the legitimate domain.
That is where the danger begins.

---

Attack Scenario #1: Malicious Redirects 🔁​

One common impact is forced redirects.

Malicious Request​

GET / HTTP/1.1
Host: www.attacker.com

Vulnerable Server Response​

HTTP/1.1 302 Found
Location: http://www.attacker.com/login.php

What does this mean?​

The user thinks they are interacting with the real website…
but the server redirects them directly to an attacker-controlled page.
This can be used for:

• Phishing attacks 🎣
• Password theft 🔑
• Session hijacking 🍪

---

Attack Scenario #2: Wrong Virtual Host Access 🏗️​

Many servers host multiple applications on the same IP address.
If an attacker manipulates the Host header, the server might:

• Route requests to the wrong virtual host
• Expose hidden applications
• Bypass security restrictions
• Reveal internal environments

Sometimes misconfigured servers respond with the first configured site by default.
That can accidentally expose sensitive systems.

---

Attack Scenario #3: Bypassing Protection Using X-Forwarded-Host 🕵️​

Some developers validate the Host header correctly…
but forget another important header: X-Forwarded-Host
Example:

Host: www.example.com
X-Forwarded-Host: www.attacker.com

If the application uses X-Forwarded-Host to generate URLs, problems appear.
Generated HTML may become:

<link src="http://www.attacker.com/link" />

Now the page contains attacker-controlled resources.

---

Attack Scenario #4: Web Cache Poisoning ☠️​

This is one of the most dangerous outcomes.

How it works​

Many websites use caching to improve speed.
An attacker sends: Host: www.attacker.com
The vulnerable server generates content containing attacker URLs:

<script src="http://www.attacker.com/payload.js"></script>

Then…
the poisoned response gets stored inside the cache.

The result?​

Normal users later receive the infected cached version.
Possible consequences:

• Malicious JavaScript loading ⚠️
• Cookie theft 🍪
• Mass XSS attacks 💥
• Redirecting visitors to attacker infrastructure

---

Attack Scenario #5: Password Reset Poisoning 🔓​

This is one of the most famous Host Header Injection attacks.
Some applications generate password reset links dynamically using the Host header.
Expected behavior: https://example.com/reset?token=XYZ
Vulnerable behavior: http://www.attacker.com/reset?token=XYZ
because the attacker changed the Host value.

What happens next?​

1. Victim requests password reset
2. Application builds malicious URL
3. Email is sent to the victim
4. Victim clicks the link
5. Reset token reaches attacker server

Result: 🚨 Password takeover

---

What Security Testers Look For 🔍​

Security testers typically check:

1. Dynamic Host Usage​

Does the application use Host dynamically for:

• Building URLs
• Security decisions
• Redirects
• Email generation

2. Protection Bypass​

Can protections be bypassed using:

• Host header manipulation
• X-Forwarded-Host injection
• Proxy behavior
• Validation weaknesses

---

How To Test Host Header Injection 🧪​

The simplest test is surprisingly easy.
Send:

GET / HTTP/1.1
Host: attacker.com

Then observe:

• Did links change?
• Did redirects occur?
• Does the page reflect the Host value?
• Are emails using attacker domains?
• Can cache poisoning happen?

These clues often reveal vulnerable behavior.

---

The Root Cause 🧩​

The core issue is simple:

The application trusts user-controlled Host values without validation.

But applications should never blindly trust client-supplied domain information.

---

How To Prevent Host Header Injection 🛡️​

Common mitigation techniques include:

Use an Allowlist​

Only accept trusted domains.
Example logic:

allowed_hosts = ["example.com", "www.example.com"]
if host not in allowed_hosts:
    reject_request()

Reject Unknown Hosts​

Drop requests containing unexpected domains.

Avoid Dynamic Host Usage​

Do not use Host values for:

• Password reset links
• Sensitive redirects
• Security-critical logic

Be Careful With X-Forwarded-Host​

Ignore it unless coming from trusted proxies.

Configure Proxies and CDNs Correctly​

Misconfigured reverse proxies frequently create Host Injection risks.

---

Final Thoughts 🔥​

Host Header Injection may look simple…
but it can lead to powerful attacks such as:

• Malicious redirects
• Cache poisoning
• Password reset hijacking
• Protection bypasses
• Internal application exposure

All because the application trusted data controlled by the user.
And in cybersecurity, trusting unvalidated user input is often where problems begin.