Ability to set an IP allow list for *.deno.dev domains

[mac-chaffee]

What problem are you trying to solve?

I have a Deno Deploy site where I want to limit the number of requests hitting the backend to reduce costs. Without support for HTTP caching or rate limiting in Deno Deploy itself (a separate feature request), I use Cloudflare to serve this need.

So I have set up a custom domain and proxied this custom domain through Cloudflare to perform caching and rate limiting, handling 80% of my traffic. But even then, the number of requests hitting my Deno Deploy site is higher than reported in Cloudflare.

I believe the reason for this is that my *.deno.deploy domains have been discovered by scanners and is being hit directly. Even if they haven't, it's still possible for a DDoS attack to run up my bill if they just set the Host header to my domain and hit the Deno Deploy IP directly.

Describe the solution you'd like

I'd like to be able to enforce that only Cloudflare IP ranges can connect to my Deno Deploy site: https://www.cloudflare.com/ips/

Describe alternatives you've considered

There are several other techniques that Cloudflare recommends for "protecting your origin server": https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/

• All of the "Application Layer" techniques won't work because validating headers or JWTs will still count towards the request limit (and Cloudflare Tunnel wouldn't work in Deno)
• "Authenticated Origin Pulls" are probably the most secure, but it likely requires direct integration with Cloudflare to share mTLS certs.
• "Allowlist Cloudflare IP addresses" is the solution proposed in this issue. While it's true that it's "vulnerable to IP spoofing", my understanding of IP spoofing is that it usually involves spoofing the IP of specific, vulnerable servers like misconfiguration DNS resolvers, not spoofing an arbitrary IP such as a Cloudflare IP.

Alternatively, implementing rate-limiting and caching in Deno Deploy could replace much of the need for Cloudflare, as long as rate-limited and cached responses don't count towards the request limit.

Another option could be https://github.com/denoland/deploy_feedback/issues/478#issuecomment-1712845209 but wouldn't those requests still count toward the request limit?

Documentation, Adoption, Migration Strategy

Probably would be nicest if you could set rate limits and IP allow lists in the code itself, maybe in the function Deno.serve(). But a new setting in the UI is fine too.

You could even make this really flexible by letting Deno.serve() accept a list of "filter" functions or something, where it works similar to the AWS WAF. Each filter returns a value indicating whether the request should be ALLOWed, BLOCKed, or PASSed on to the next filter. Blocked requests would not count towards the request limit, or would be charged at a lower rate, scaled based on the number of filters (similar to Amazon's Web ACL Capacity Units).