Test for Host Header Injection with Burp Suite (2026)

Burp Suite can’t directly test for Host Header Injection; it’s a vulnerability you exploit by sending specially crafted requests.

Let’s see it in action. Imagine a web application that uses the Host header to determine which internal resource to serve. A typical request might look like this:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,...

The server sees Host: www.example.com and happily serves www.example.com/index.html.

Now, what if we change the Host header?

GET /index.html HTTP/1.1
Host: internal.admin.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,...

If the application is vulnerable, it might ignore the fact that the request came from an external IP and instead try to serve internal.admin.example.com/index.html. If internal.admin.example.com is an internal-only hostname or points to a sensitive administrative interface, we’ve just bypassed access controls.

Here’s how you’d actually test this with Burp Suite:

1. Proxy the Request: Configure your browser to use Burp Suite as its proxy. Navigate to the target website. Burp will capture the HTTP request.

2. Send to Repeater: Right-click on the captured request in Burp’s Proxy History tab and select "Send to Repeater."

3. Modify the Host Header: In the Repeater tab, locate the Host header in the request. Change its value to something you suspect might be an internal hostname or a different domain. Common targets include:

   • localhost
   • 127.0.0.1
   • Internal IP addresses (e.g., 192.168.1.100)
   • Known internal hostnames (e.g., admin.example.com, intranet.example.com)
   • Potentially other subdomains of the target domain.

   For instance, change Host: www.example.com to Host: localhost.

4. Send the Modified Request: Click the "Go" button in Repeater to send your modified request.

5. Analyze the Response: Examine the response from the server. Look for:

   • Different Content: Does the response content differ from the original request? This is a strong indicator of Host Header Injection.
   • Access to Internal Resources: Are you seeing pages that should only be accessible internally (e.g., administrative dashboards, internal APIs, debug pages)?
   • Error Messages: Sometimes, an injection might lead to specific error messages that reveal internal paths or configurations.
   • Redirects: The application might redirect you to an internal-only URL.

Automating with Intruder: For more systematic testing, you can use Burp’s Intruder.

1. Send to Intruder: Right-click on a request in Proxy History or Repeater and select "Send to Intruder."
2. Clear Payload Positions: In the "Positions" tab of Intruder, clear all default payload positions.
3. Add Host Header Position: Manually add the Host header line as a payload position. Click "Add §" on the Host header line.
4. Configure Payload Types: Go to the "Payloads" tab.
   • Payload type: "Simple list."
   • Payload Options: Add a list of potential Host header values to test. This list should include localhost, 127.0.0.1, internal IPs you might discover, common administrative hostnames, and other subdomains.
5. Start Attack: Click "Start attack." Intruder will send a request for each payload, systematically trying to inject different hostnames.
6. Analyze Results: Sort the results by response length or status code. Look for anomalies that indicate successful injection.

The core problem this bypasses is server-side logic that relies solely on the Host header for routing or access control. When an attacker can control this header, they can trick the server into thinking the request is for a different host, often an internal one, thus gaining unauthorized access or revealing sensitive information. The Host header is supposed to reflect the domain name the client intended to connect to, but many applications don’t validate it against the actual server it’s running on or the client’s origin IP.

One subtle point is that even if the application doesn’t directly serve different content based on the Host header, it might use it for generating absolute URLs in its responses. If the Host header is injected with an attacker-controlled domain, these generated URLs could point to malicious sites, leading to a different class of vulnerability like Open Redirect or even XSS if those URLs are then rendered unsafely. This means the impact isn’t always about seeing internal pages, but also about manipulating outbound links.

The next hurdle after successfully exploiting Host Header Injection is often identifying what specific internal resources are accessible and what actions can be performed on them.