denoland / denoland/deploy_feedback
Ability to set an IP allow list for *.deno.dev domains
- Dominant language
- No language data
- Stars
- 79
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
### 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](https://blog.cloudflare.com/the-root-cause-of-large-ddos-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](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-action.html). Each filter returns a value indicating whether the request should be `ALLOW`ed, `BLOCK`ed, or `PASS`ed 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](https://docs.aws.amazon.com/waf/latest/developerguide/aws-waf-capacity-units.html)).
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.