Understanding and Exploiting HTTP Host Header Attacks

HTTP Host Header Attacks

This section discusses how incorrect configuration and flawed business logic can allow a website to be compromised via the HTTP Host header. It outlines high‑level methods for identifying sites vulnerable to Host header attacks, demonstrates exploitation techniques, and offers general mitigation advice.

What Is the HTTP Host Header?

Since HTTP/1.1, the Host header is mandatory and specifies the domain the client wants to reach. For example, when a user visits https://portswigger.net/web-security , the browser sends a request that includes:

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

In some scenarios, such as when a request passes through an intermediary, the Host value may be altered before reaching the intended backend component.

Purpose of the HTTP Host Header

The Host header tells the server which backend component the client intends to communicate with. Missing or malformed Host headers can cause routing problems.

Historically, each IP address hosted a single domain, so ambiguity was rare. Today, cloud‑based solutions and IPv4 exhaustion mean many sites share an IP address, making the Host header essential for virtual hosting.

Virtual Hosting

A single web server may host multiple sites (owned by the same or different parties) that share one IP address. This is known as virtual hosting.

Routing Through an Intermediary

Often, traffic is routed through a load balancer or reverse proxy (e.g., a CDN). All domains resolve to the intermediary’s IP, which must then use the Host header to forward the request to the correct backend.

How the Host Header Solves the Problem

Just as a letter to an apartment building needs a room number, the Host header identifies the specific virtual host or application that should handle the request.

What Is an HTTP Host Header Attack?

Host header attacks exploit applications that trust the Host header without proper validation or sanitisation. By injecting malicious payloads into the Host header, an attacker can manipulate server‑side behaviour (known as "Host header injection").

Many web apps retrieve the current domain from the Host header to generate URLs (e.g., in password‑reset emails):

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

The header’s value can also be used for inter‑system communication, making it a potential carrier for other vulnerabilities such as:

Web cache poisoning

Business‑logic flaws in specific features

Routing‑based SSRF

Typical server vulnerabilities like SQL injection

How HTTP Host Vulnerabilities Arise

They usually stem from the false assumption that the Host header is immutable, leading to implicit trust and lack of validation or escaping.

Even when the Host header is handled securely, other headers can overwrite it depending on server configuration, and many developers are unaware of such possibilities.

Often the root cause is insecure configuration of third‑party components integrated into the architecture.

How to Test for HTTP Host Header Vulnerabilities

Testing requires an intercepting proxy (e.g., Burp Suite) and tools like Burp Repeater or Intruder to modify the Host header and observe the application’s response.

Provide an Arbitrary Host Header

Send a request with a random, unrecognised domain in the Host header and see how the server reacts. Some proxies forward the request based on the IP address, while others (like Burp) keep the Host header separate, allowing you to test ambiguous or malformed values.

Check for Validation Defects

Some applications only compare the Host header to the TLS SNI value, which does not guarantee immunity. Others may ignore the port component, allowing payloads via "bad‑stuff‑here" ports.

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

Some sites allow any sub‑domain that ends with a whitelisted domain, enabling sub‑domain takeover attacks.

GET /example HTTP/1.1
Host: notvulnerable-website.com

Send Ambiguous Requests

Techniques include injecting duplicate Host headers, providing an absolute URL in the request line, or adding leading spaces (line‑wrapping) to create differences between front‑end and back‑end handling.

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

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

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

Inject Headers That Override Host

Front‑end servers can inject X-Forwarded-Host (or similar headers like X-Host , X-Forwarded-Server , X-HTTP-Host-Override , Forwarded ) to convey the original Host value. Many frameworks trust these headers, allowing an attacker to bypass Host validation.

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

How to Exploit HTTP Host Header Vulnerabilities

Once an arbitrary hostname can be supplied, attackers can perform several attacks:

Password‑reset poisoning

Web cache poisoning

Exploiting typical server‑side vulnerabilities (e.g., SQL injection)

Bypassing authentication or access controls

Brute‑forcing internal virtual hosts

Routing‑based SSRF

Password‑Reset Poisoning

By controlling the Host header, an attacker can cause the password‑reset email to contain a link pointing to a domain they control, allowing them to capture the reset token.

Web Cache Poisoning via Host Header

If a web cache uses the Host header as part of its cache key, an attacker can inject a malicious payload into the cached response and serve it to other users.

Leveraging Typical Server‑Side Bugs

If the Host value is concatenated into SQL queries or other server‑side code, classic injection attacks become possible.

Bypassing Restricted Functions

Some internal features rely on the Host header for access control; manipulating it can grant unauthorized access.

Brute‑Forcing Internal Virtual Hosts

Attackers can guess internal hostnames or use leaked sub‑domains to reach private services hosted on the same server.

Routing‑Based SSRF

Manipulating the Host header can cause a mis‑configured reverse proxy or load balancer to forward requests to arbitrary internal systems, effectively turning the Host header into an SSRF vector.

Tools like Burp Collaborator can be used to detect such behavior by observing DNS queries to a controlled domain.

Defending Against HTTP Host Header Attacks

The simplest defence is to avoid using the Host header in server‑side code. Prefer relative URLs whenever possible.

Additional mitigations include:

Hard‑code the expected domain in configuration and reference it instead of the Host header.

Validate the Host header against a whitelist of allowed domains (e.g., Django’s ALLOWED_HOSTS ).

Disable or ignore headers that can overwrite the Host header, such as X-Forwarded-Host .

When using internal virtual hosts, keep them isolated from publicly exposed servers.

Password Reset Poisoning

Password‑reset poisoning is a technique where an attacker manipulates the Host header so that the password‑reset link in the email points to a domain they control, allowing them to capture the reset token and hijack the victim’s account.

How Password Reset Works

User submits a username or email address to request a password reset.

The site generates a unique, high‑entropy token and stores it.

An email is sent containing a link such as https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j .

The user clicks the link, the server validates the token, and the password is reset.

The process is safe only if only the legitimate user can access the email. By controlling the Host header, an attacker can cause the link to point to https://evil-user.net/reset?token=… , stealing the token.

Constructing a Password Reset Poisoning Attack

Attacker obtains the victim’s email address and submits a password‑reset request with a malicious Host header (e.g., evil-user.net ).

The victim receives an email with a reset link that points to the attacker’s domain.

When the victim clicks the link, the token is sent to the attacker’s server.

The attacker uses the token to reset the password on the legitimate site and gains account access.

Even without controlling the reset link, an attacker may inject HTML into emails via the Host header, leading to other injection attacks.