[malthejorgensen]

Thank you so much for this reply!

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.

[kentonv]

Limiting Workers to only be able to talk to servers that had "opted in" would be too limiting. Lots of people use Workers to talk to third-party APIs. And, many people are building whole applications entirely on Workers, with no origin server at all.

> 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. :/