denoland / denoland/deploy_feedback

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

Open
#814 0 comments 10 reactions 0 assignees View on GitHub
enhancement
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.