Host Header Injection Detection Techniques

Host Header Injection is a common but dangerous web vulnerability that can lead to serious issues like password reset poisoning, cache poisoning, open redirects, and SSRF.

In this guide, you’ll learn practical and real-world ways to detect Host Header Injection vulnerabilities, using simple techniques that every pentester, bug bounty hunter, and security researcher should know.

What Is Host Header Injection? 🧠​

Host Header Injection happens when a web application trusts the Host header sent by the client without proper validation.
Normally, a request looks like this:

GET /admin.php HTTP/1.1
Host: target.com

If the application blindly uses this value in redirects, emails, or links, an attacker can manipulate it 🚨.

---

Why Host Header Injection Is Dangerous ⚠️​

This vulnerability can be abused to:

• Poison password reset links
• Bypass authentication
• Perform cache poisoning attacks
• Abuse reverse proxy configurations
• Enable phishing attacks

That’s why it’s a high-value finding in bug bounty programs 💰.

---

Test 1: Adding a Malicious Prefix 🧪​

Try modifying the Host header with a fake domain:

GET /admin.php HTTP/1.1
Host: hackertarget.com

🔍 If the response reflects or trusts this value, the app may be vulnerable.

---

Test 2: Using an Absolute URL in the Request Line 🌐​

Some servers accept absolute URLs instead of paths:

GET https://target.com/admin.php HTTP/1.1
Host: attacker.com

🚩 If the app uses attacker.com internally, this is a strong indicator.

---

Test 3: Subdomain Injection 🔑​

Try sending a subdomain of the target:

GET /admin.php HTTP/1.1
Host: subdomain.target.com

💡 Misconfigured apps may treat this as a trusted domain.

---

Test 4: Changing the Port Number 🔌​

GET /admin.php HTTP/1.1
Host: target.com:8080

If the app includes the port in generated links, it may be exploitable.

---

Test 5: Using the Target IP Address 🖥️​

GET /admin.php HTTP/1.1
Host: 192.168.1.10

This often exposes weak virtual host validation.

---

Test 6: Multiple Host Headers 🧩​

Send more than one Host header:

GET /admin.php HTTP/1.1
Host: target.com
Host: attacker.com

Some servers process the last Host header, others the first - both can be abused.

---

Test 7: Blank Host Header 🚫​

GET /admin.php HTTP/1.1
Host:
X-Forwarded-Host: attacker.com

This tests fallback behavior in reverse proxy setups.

---

Test 8: X-Forwarded-Host Header 🔄​

GET /admin.php HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com

Many applications trust this header when behind load balancers.

---

Test 9: Other Proxy Headers 🧪​

Some servers accept alternative headers:

X-Host: attacker.com
X-Forwarded-Server: attacker.com
X-HTTP-Host-Override: attacker.com
Forwarded: host=attacker.com

🚨 These are often forgotten during security hardening.

---

Test 10: Another Website on the Same IP 🌍​

GET /admin.php HTTP/1.1
Host: target2.com

If multiple sites share the same IP, virtual host confusion can occur.

---

How to Confirm the Vulnerability ✅​

A Host Header Injection is confirmed if:

• The Host value appears in redirects
• Password reset emails contain attacker-controlled domains
• Absolute URLs use the injected host
• Cache behavior changes

Always try to prove real impact 🎯.

---

Tools That Help with Host Header Testing 🛠️​

• Burp Suite
• OWASP ZAP
• curl
• Custom scripts

Example with curl:

curl -H "Host: attacker.com" https://target.com

---

Best Practices for Bug Bounty Hunters 💡​

✔️ Test all endpoints, not just login
✔️ Focus on password reset functionality
✔️ Combine with cache poisoning
✔️ Test behind proxies and CDNs
✔️ Document impact clearly

Final Thoughts 🔐​

Host Header Injection vulnerabilities are often overlooked but can lead to critical security issues if exploited correctly.
By mastering these techniques, you significantly increase your chances of finding high-impact bugs in real-world applications 🚀.