Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →A Host header tells a web server which host name and optional port a request is addressed to. It matters when one server handles multiple websites or services. In HTTP/1.1, every request must include a Host field; in HTTP/2, the :authority pseudo-header carries the authority when present. Because host values can affect routing and generated links, applications should validate them rather than trust them.
What does a Host header do?
One server address can serve several named websites. The host value helps the server select the intended destination among the host names it serves. The IETF defines Host as carrying host and port information from the target URI so an origin server can distinguish among resources while serving multiple host names (RFC 9110 §7.2).
For example, a request to http://www.example.org/where?q=now can look like this in HTTP/1.1:
GET /where?q=now HTTP/1.1
Host: www.example.orgThe request target, /where?q=now, gives the path and query. The Host field identifies the requested host. If the URI authority includes a port, the host value includes the port as applicable. When an HTTP/1.1 request target has an authority component, Host must match that authority, excluding user information.
#1 Best Overall
Host is request metadata at the application layer. It does not perform DNS resolution, and it does not prove that a server is authentic. With HTTPS, the secured connection and certificate validation are part of establishing the authenticated connection; a Host value is not a security credential (RFC 9110 §§4.2, 4.3).
How HTTP/1.1 and HTTP/2 carry the host
| Aspect | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Authority field | The Host field is required in every request. | The :authority pseudo-header carries the authority when present. |
| How the target is determined | Host corresponds to the target URI authority when the request target includes one. | If :authority is present, the recipient must not use Host to determine the target URI. |
| Translation to HTTP/1.1 | Not applicable. | An intermediary generating an HTTP/1.1 request must derive Host from :authority, unless it changes the request target. |
| Standard | RFC 9112 §3.2 | RFC 9113 §8.3.1 |
For HTTP/1.1, the requirement is strict: a client must send Host in every request. A server must return 400 Bad Request for a missing, repeated, or invalid Host field line (RFC 9112 §3.2).
HTTP/3 also uses :authority in place of Host in the relevant cases; RFC 9110 groups HTTP/2 and HTTP/3 on this point. The details above focus on HTTP/1.1 and HTTP/2.
Why unvalidated Host values can be dangerous
Servers and applications may use a host value to route a request or create an absolute URL. If an application accepts an unexpected value, the result can be more than a request going to the wrong site. OWASP identifies these possible outcomes of insufficient validation:
Rank #3
- Used Book in Good Condition
- Dispatch to an unintended virtual host, including a default or first virtual host.
- Redirects to a domain controlled by an attacker.
- Web cache poisoning.
- Password-reset link manipulation.
- Access to virtual hosts that were not intended to be public.
These are possible consequences, not proof that any particular site is vulnerable. OWASP’s testing guidance discusses checking behavior by supplying another domain in Host, and notes that systems filtering Host may also use X-Forwarded-Host (OWASP Web Security Testing Guide: Host Header Injection). Such testing should be limited to systems you own or are authorized to assess.
The risk is part of a broader input-handling rule: request fields are untrusted data. RFC 9110 warns that applications can create injection vulnerabilities when they pass request data, including Host, unsafely to commands, interpreters, or database queries (RFC 9110 §17.4).
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to handle Host safely
- Configure an explicit allowlist, or an equivalent validation rule, for the host names the application serves.
- Do not blindly use Host to construct redirects or password-reset links; build such URLs from trusted configuration or validated values.
- When a proxy or intermediary translates HTTP/2 to HTTP/1.1, keep Host aligned with
:authorityunless the request target is intentionally changed. - Treat forwarded host fields such as
X-Forwarded-Hostas untrusted unless the application’s trusted-proxy configuration establishes their provenance.
These are defensive implementation practices derived from the routing and injection risks described by the standards and OWASP guidance; they are not a claim that every server handles host values in the same way.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
