Host Header Injection: Prevention Guide

Host header injection is a simple yet powerful web vulnerability. When a server trusts the client-supplied Host header without validating it, attackers can manipulate links, poison caches, bypass protections, and perform phishing. This guide explains how Host header attacks work, real examples, testing tips, and practical prevention steps you can apply right now.

What is a Host Header Attack? ​

A Host header attack happens when a web application uses the HTTP Host header directly - for example, to build links, redirects, or password reset URLs - and the server fails to validate that header. Since clients can send arbitrary Host values, an attacker can replace the real host with an attacker-controlled domain and force the app to generate URLs that point to that domain.

Common consequences:

• Web cache poisoning
• Password reset poisoning
• Open redirect / phishing
• Bypassing same-origin checks or access controls

Understanding this threat matters because it’s easy to test for and often overlooked by developers.

How the Host Header Works (Example) ​

A normal HTTP request looks like this:

GET / HTTP/1.1
Host: vulnerable-website.com

An attacker can send:

GET / HTTP/1.1
Host: attacker.com

If your application constructs links using the raw Host, e.g.:

$reset_link = "https://" . $_SERVER['HTTP_HOST'] . "/reset?token=abc123";

and the attacker sets Host: evil.com, the app will produce:

https://evil.com/reset?token=abc123

If that link is emailed to the victim, the attacker may intercept or harvest tokens - a direct account takeover vector.

Vulnerable Use-Cases (Where to Look) ​

Look for these risky behaviors in your codebase:

• Building password reset links using Host or HTTP_HOST
• Redirects constructed from the request host or headers
• Canonical URL generation that uses Host
• Multi-tenant apps that rely on Host to map tenants without strict checks
• Email-confirmation or invite links built from the request

These are the most common places where Host header manipulation leads to impact.

Real Example: Password Reset Poisoning ​

1. App code builds reset links from Host.
2. Attacker sends a request with Host: evil.com.
3. App generates a reset link pointing to evil.com.
4. Email service sends the link to a victim, who may click it.
5. Attacker-controlled domain receives the request with the token (or trick victims to enter credentials).

This is why building URLs from untrusted headers is dangerous.

How to Test for Host Header Issues (Tools & Commands) ​

Quick tools to test:

• Burp Suite - intercept requests and edit the Host header.
• curl - simple command-line test:

curl -I -H "Host: evil.com" http://target.com/

• Web proxies and intercepting proxies help you try different hosts and observe the app’s behavior (redirects, links, email payloads).

Search the app for places that generate absolute URLs or redirects - those are high-value targets.

---

Concrete Prevention Techniques (Do these now) ​

1. Whitelist trusted hosts​

Only accept requests where the Host header matches a known list. Reject or drop requests with unknown hosts.

Example (pseudo-code):

if request.host not in ['yourdomain.com', 'www.yourdomain.com']:
    abort(400)

Make sure this check sits as early as possible in request handling.

2. Use server-side configuration to enforce hosts​

Block or drop requests at the web server level (faster and safer).
Nginx example:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    if ($host !~ ^(yourdomain\.com|www\.yourdomain\.com)$ ) {
        return 444;
    }

    # ... other config ...
}

Alternatively, set a default server block that rejects unknown hosts.

3. Avoid building critical URLs from Host​

Use a fixed canonical base URL from configuration (e.g., APP_BASE_URL) when creating password reset links, emails, or redirects.

Example (safer approach):

$base = 'https://yourdomain.com';
$reset_link = $base . "/reset?token=" . $token;

This removes reliance on client-supplied headers.

4. Validate proxy headers carefully​

If your app is behind a proxy or CDN (Cloudflare, ELB, etc.), trust only the proxy’s known headers and configure the proxy to pass a validated Host or a trusted header. Block X-Forwarded-Host and similar headers unless you explicitly trust their source.

5. Use canonicalization & origin checks​

When generating redirects or performing sensitive logic, validate that the target host belongs to your domain list. For example, only redirect to whitelisted domains - never to an arbitrary host provided by the user.

6. Sanitize all header-derived values​

Treat header values as untrusted input. Sanitize and normalize them before use. Don’t assume they are well-formed or safe.

Server & Proxy Best Practices ​

• Configure the web server to respond only to expected server_name / Host values.
• If using containers or orchestration, ensure ingress controllers validate incoming hosts.
• For multi-tenant apps, use a secure mapping from hostname to tenant stored server-side; don’t let the host header define security boundaries without verification.

Bug Bounty & Pentest Tips ​

Host header injection is often low-hanging fruit. When pentesting or hunting bugs:

• Search for password reset and email generation code.
• Check canonical tags, redirects, and any functionality that outputs a full URL.
• Test X-Forwarded-Host, X-Host, and other proxy-style headers.
• Report practical impact: token exposure, phishing potential, cache poisoning - those drive higher rewards.

Reported impacts can range widely depending on UAT: from small $100 reports to $5,000+ for account takeover or mass impact.

Quick Reference: Example Commands & Tests ​

• Test host header with curl:

curl -I -H "Host: evil.com" http://target.com/

• Intercept and modify Host header with Burp or any intercepting proxy - then observe redirect locations or generated links.

Conclusion - Never Trust Client Headers ​

Host header attacks are simple to understand and often simple to fix. The common theme across prevention methods is: do not trust client-controlled data for security-critical operations. Use server-side whitelists, fixed base URLs for email and redirects, and harden your server/proxy configuration.

Keep your app safe by:

• Validating hosts early
• Avoiding header-derived URL building
• Configuring web servers to reject unknown hosts

If you follow these steps, you remove an entire class of practical attacks that are easy for attackers to exploit but also easy to fix. Share this guide with your dev team and include Host header checks in your security reviews.