Attacks on the Host header: understand and protect yourself
The HTTP “Host” header may seem harmless and purely technical. Yet, if poorly validated or used without caution, it becomes an entry point for discreet attacks with sometimes severe consequences.
What is the Host header used for?
The “Host” header is mandatory in an HTTP request: it indicates the domain (and possibly the port) of the requested resource. It enables the server to route the request to the right site when several domains share the same IP address.
A common mistake is to believe that this header cannot be manipulated by the user. Yet, like any field in an HTTP request, it can be modified. If it is poorly validated or reused as-is by the application, it opens the door to several attacks, a classic in penetration testing.
Possible attacks
Hijacked password reset
If the password reset link is built from the Host, the attacker can point the link to their own domain and capture the token.
Cache poisoning
Inject a malicious Host to cause booby-trapped responses to be cached, then served to other users.
Routing & bypass
Deceive routing or access-control logic that relies on the Host to distinguish between environments.
Open redirects
Generate redirects to a domain controlled by the attacker, used for phishing or token theft.
Misplaced trust
The common thread in these attacks is unjustified trust placed in data supplied by the client. The most telling case is password reset: by tampering with the Host, an attacker can receive the link instead of the victim and take over the account, a scenario similar to those described in account takeover. Here again, the rule is never to blindly trust input.
The principle: do not trust the supplied Host
Protecting yourself means not using the Host header as a trusted value. Validate the Host against an allowlist of authorized domains, rely on a server-side configured base URL (not the request Host) to generate absolute links (especially for resets), and harden the server and cache configuration. These points are checked during an penetration test application.
Protect yourself, step by step
Validate with an allowlist
Accept only explicitly authorized domains and reject any unexpected Host.
Use a fixed base URL
Generate links (including reset links) from a server configuration, never from the request Host.
Harden the web server
Configure a safe default host and reject requests with an unrecognized Host.
Secure the cache
Prevent manipulable headers from entering the cache key, to prevent poisoning.
Control redirects
Do not redirect to a destination derived from a header controllable by the user.
Why work with BCIT?
Targeted tests
We thoroughly test how the Host is handled, especially in sensitive flows such as resets.
Simple fixes
Allowlist, base URL, hardening: clear and actionable measures.
A complete overview
From application security to audits, the entire chain.
Not ready to talk yet? Discover our cybersecurity assessment →
A harmless-looking header should not cost you an account 🚀
Let’s take 15 minutes to check how the Host header is handled in your applications and secure sensitive flows.
Attacks on the Host header: understand and protect yourself
The HTTP “Host” header may seem harmless and purely technical. Yet, if poorly validated or used without caution, it becomes an entry point for discreet attacks with sometimes severe consequences.
What is the Host header used for?
The “Host” header is mandatory in an HTTP request: it indicates the domain (and possibly the port) of the requested resource. It enables the server to route the request to the right site when several domains share the same IP address.
A common mistake is to believe that this header cannot be manipulated by the user. Yet, like any field in an HTTP request, it can be modified. If it is poorly validated or reused as-is by the application, it opens the door to several attacks, a classic in penetration testing.
Possible attacks
Hijacked password reset
If the password reset link is built from the Host, the attacker can point the link to their own domain and capture the token.
Cache poisoning
Inject a malicious Host to cause booby-trapped responses to be cached, then served to other users.
Routing & bypass
Deceive routing or access-control logic that relies on the Host to distinguish between environments.
Open redirects
Generate redirects to a domain controlled by the attacker, used for phishing or token theft.
Misplaced trust
The common thread in these attacks is unjustified trust placed in data supplied by the client. The most telling case is password reset: by tampering with the Host, an attacker can receive the link instead of the victim and take over the account, a scenario similar to those described in account takeover. Here again, the rule is never to blindly trust input.
The principle: do not trust the supplied Host
Protecting yourself means not using the Host header as a trusted value. Validate the Host against an allowlist of authorized domains, rely on a server-side configured base URL (not the request Host) to generate absolute links (especially for resets), and harden the server and cache configuration. These points are checked during an penetration test application.
Protect yourself, step by step
Validate with an allowlist
Accept only explicitly authorized domains and reject any unexpected Host.
Use a fixed base URL
Generate links (including reset links) from a server configuration, never from the request Host.
Harden the web server
Configure a safe default host and reject requests with an unrecognized Host.
Secure the cache
Prevent manipulable headers from entering the cache key, to prevent poisoning.
Control redirects
Do not redirect to a destination derived from a header controllable by the user.
Why work with BCIT?
Targeted tests
We thoroughly test how the Host is handled, especially in sensitive flows such as resets.
Simple fixes
Allowlist, base URL, hardening: clear and actionable measures.
A complete overview
From application security to audits, the entire chain.
Not ready to talk yet? Discover our cybersecurity assessment →
A harmless-looking header should not cost you an account 🚀
Let’s take 15 minutes to check how the Host header is handled in your applications and secure sensitive flows.