https://developers.cloudflare.com/workers/runtime-apis/reque...
The reason we don't allow setting the `Host` header different from the hostname used for routing purposes has nothing to do with "The Web Platform", but rather is important to protect the security of other Cloudflare customers specifically.
Cloudflare customers rely on Cloudflare to block attacks directed at their origin server. This only works if the attacker cannot simply bypass Cloudflare and talk to the origin directly. So, origins need to verify that requests actually came through Cloudflare. The best way to do that is to use Argo Tunnel or Authenticated Origin Pulls (with a unique customer-provided keypair). However, many customers instead rely on firewalling their origin so that it only accepts traffic from Cloudflare's IP ranges.
The problem with this is that anyone can sign up for a Cloudflare account and plug in your origin's IP address as their own. Then, when they send requests to their domain through Cloudflare, those requests will be sent to your origin -- coming from Cloudflare IPs! We have no way to authenticate that the origin IP address actually belongs to the customer.
The main thing that mitigates this attack is that the requests will end up having the `Host` header set to the attacker's domain, not yours. So if your origin server only accepts requests with a `Host` header it recognizes, then you are OK.
Now enter Workers. Workers allow customers to make requests to anywhere on the internet -- from Cloudflare IPs! If the request is directed to another Cloudflare customer, though, we'll treat it as a request coming from the internet, and apply that other customer's security settings. So this does not allow an attacker to bypass Cloudflare's security protections on other customers' domains. But if the attacker could make a request to their own origin, while rewriting the `Host` header to match the victim's hostname, then they could set the victim's origin as their own as described above, while bypassing the `Host` header mitigation. We can't allow that.
`resolveOverride`, however, only works when fetching to hostnames within your own zone, essentially allowing you to rewrite your host's DNS mapping on the fly. Since you already have the power to modify your own DNS, this does not give an attacker any new capabilities. Meanwhile, it solves most use cases where people want to rewrite the `Host` header.
==========================
All that said, it's not clear to me if your use case needs Workers. Could you have configured the DNS entry for www.peergrade.io to be a CNAME of peergrade.wpengine.com? That would cause Cloudflare to forward requests to peergrade.wpengine.com while still having `Host: www.peergrade.io`, which seems like what you want?
==========================
FWIW, the reason we chose "The Web Platform" instead of Node is because web APIs are described by standards that are intended to have multiple implementations, whereas Node's APIs are defined by their implementation. We can't literally use Node.js's implementation because it isn't a sandbox and it doesn't scale to support thousands of tenants on a single machine, which are both critical to the edge compute use case. So, to support Node, we would have to re-implement the Node APIs from scratch. This is something we're considering doing in the future, but it was much easier to get started implementing standardized web APIs.
Cloudflare Workers as a way of bypassing whitelisted Cloudflare IPs makes a lot of sense, and of course is an attack vector that needs to be mitigated. Now I'm really dreaming – but it would be really neat to have a mechanism similar to LetsEncrypt where you could prove ownership of a domain and allow arbitrary requests to that domain. Given the potential throughput of Cloudflare Workers, it could be valuable as a safeguard even in the current setup (I'm guessing it's possible to amplify one request quite a lot which could annoy a victim server even with if the requests have the wrong `Host`-header?).
You're partially right about the CNAME. The reason I ended up needing workers is to preserve the cookie check that I currently have (implemented in NGINX/Lua) which redirects to app.peergrade.io if a session cookie is set (the cookie is scoped to the top-level domain). Not the neatest, but it used be quite common -- Heroku still does something similar.
I didn't think about Node not being as set-in-stone-standard as The Web Platform and not being sandboxed. An example of where the current setup is awkward would be using `atob` and `btoa` with actual binary data, I had this case when unpacking base64-data in the cookie.
> I'm guessing it's possible to amplify one request quite a lot which could annoy a victim server
We have other defenses against this. :)
> `atob` and `btoa`
These are indeed awful and I wish browsers would define something better. :/
