Not possible to override the Host header on Workers requests

workers

#1

I noticed that it’s not possible to override the Host header on requests. After a bit of digging I found that the Host header is forbidden in the Fetch API:

I think I understand why it’s not possible to set a custom Host in the browser, but for Cloudflare Workers it really puts a damper on conditional proxy applications. Is it possible to relax this restriction? I think it would make sense for Cloudflare Workers.


Cloudflare Workers Beta Feedback
#2

Hi @dan42,

fetch() ignores your setting for the Host header because it initializes the Host header based on the request URL – which you can set! For example, you can do:

fetch("https://www.example.com")

Your worker is free to fetch any URL accessible from the public internet.

If you want to rewrite the URL of your incoming request to go to a different host, you could do something like:

addEventListener("fetch", event => {
  let newUrl = new URL(event.request.url);
  newUrl.hostname = "www.example.com";
  event.respondWith(fetch(newUrl, {
    method: event.request.method,
    headers: event.request.headers
  }));
});

(Sorry that that’s a bit verbose. I’m working with the spec authors to see if we can make it simpler.)

Does that solve your problem, or have I misunderstood?


#3

Hi @dan42,

It occurred to me that you might be trying to set up a request that is routed to an IP address based on one hostname, but reports a different hostname in the Host header. This might make sense for example to reroute some requests to a test server that is configured exactly the same as the original server, so expects the same Host header.

Unfortunately, we can’t allow you to specify a Host header that is inconsistent with the routing for security reasons: Many Cloudflare customers protect their origin by whitelisting Cloudflare’s IP address, using authenticated origin pulls, or other ways, and they rely on the Host header to prove that Cloudflare executed the security settings for their site.

However, now that I think of it, the attack scenario I’m thinking requires the attacker to override a Host header to specify the victim’s zone. I believe we could safely allow you to override the Host header as long as the overridden value identifies a zone you control. Or, a different way of thinking about this is, we could allow you to override your origin’s DNS configuration for a single request. We will look into this.


Authenticated Origin Pulls per Client
#4

Hi @KentonVarda,

Yes, that’s what I meant; route to an IP based on one hostname but use a different Host header. I never imagined it could be an attack vector but now that you explain it I can see it indeed.

To give you some context, what I’m trying to do is similar to the stackoverflow question I linked above. Request arrives to www.animenewsnetwork.com and based on some routing logic, either send it to the origin server or to wwwezo.animenewsnetwork.com which is an additional reverse proxy which then forwards the request to the origin (and performs some transformations on the response; see ezoic.com for details; actually they’re a Cloudflare partner I believe). But for that additional reverse proxy step I would like the Host header to remain “www.animenewsnetwork.com”.


#5

Hi @dan42,

Thanks for the feedback, and apologies for misunderstanding at first. I’m looking into implementing an “origin DNS override” feature in the next few weeks.


#6

Hi @KentonVarda, may I ask for an update on this feature? I’d like to know if you’re still planning to implement it or not. Thanks.


#7

Hi @dan42,

Oops, this feature was added a couple weeks ago but I forgot to update the thread. It’s documented here:


#8

Awesome! Thanks :slight_smile: