Host Header Injection

What Is Host Header Injection?

Applications build password-reset links from the incoming request's Host or X-Forwarded-Host header, which lets the requester decide where they point. You'll rebuild a reset request with a lookalike domain in X-Forwarded-Host , let the application mail a real token on your link, and replay it inside its lifetime to own the account. Then you build the base URL from a configured APP_BASE_URL rather than request data, backed by a Host allow-list at the proxy. The same shape hides in signed download URLs and cache keys.

What You'll Learn in Host Header Injection

• Recognize <code>req.headers.host</code> as untrusted input, the header identifies the requester's claim about where they sent the request, not the application's identity
• Apply the configured-constant fix: build URLs from <code>process.env.APP_BASE_URL</code> (set per environment in deployment config), never from request-derived values
• Pair with a strict Host-header allow-list at the framework or proxy level so any other call site still reading the header is hardened
• Audit every URL-building site (email templates, signed download URLs, redirects, cache keys, email footers) for the same anti-pattern
• Internalize: an attacker controls request headers, an operator controls deployment configuration, security-sensitive URL bases belong on the operator side of that line

Host Header Injection — Training Steps

1. Use the reset feature

   Bob is after Verdanta accounts. It is a personal-finance app, so every account he takes over links straight to someone's real bank balances. He does not know anyone's password, so he starts where he does not need one: the forgot-password page. First he submits it with a throwaway address of his own, so he can watch exactly what request the page makes.

2. Find the endpoint

   The request went out and the browser recorded it. Bob opens the Network panel to read where the page actually sent it.

3. Read the body schema

   One request, and it tells Bob everything he needs. He checks what the page put in the request body.

4. Forge the reset request

   Bob rebuilds that same request in the API Tester, where he can add one thing a browser form never lets him set: a forged host header. He asks for a reset on Alice's real account but tells the app the request arrived at account-verdanta.app, a lookalike domain he registered and controls (note the .app, where Verdanta's real site is account.verdanta.com). If the app builds the reset link from the header, Alice's email will carry his domain and her real token.

5. The response gives nothing away

   The API answers with a plain 200 and a generic message. Nothing in the response hints that anything went wrong, that is exactly why this bug is quiet. The damage is not in the response Bob can see. It is in the email now sitting in Alice's inbox, carrying a link that starts with his domain.

6. A password-reset email

   Off the clock, Alice gets a password-reset email from Verdanta. She did not ask for one, but it looks exactly like the real thing: same sender, same wording, same layout.

7. Click the reset link

   Alice clicks the link to reset her password, exactly the way anyone would.

8. Look at the address bar

   The reset page opens. It looks like Verdanta, but the address bar tells a different story.

9. Catch the token

   Alice's click never reached Verdanta. Her browser opened account-verdanta.app, the server Bob controls, and the reset token rode along in the URL. Back on his own machine, Bob tails the access log for that server to catch what just arrived.

10. Replay the token

    The token is Alice's, but it is in Bob's hands now, and reset tokens do not care who presents them. Before it expires, he replays it against the real endpoint and sets a password of his own choosing.