Outsource IP determination for throttling

[timmc]

By default, DRF currently takes the entire X-Forwarded-For header as a rate-limiting key component for unauthenticated users. This allows trivial bypass of rate-limiting. There's also a NUM_PROXIES option which can be configured, but this has several downsides.

Downsides of NUM_PROXIES:

• Only works when there's a consistent, known number of proxies, which unfortunately is not true in many applications
• Makes migration from one network configuration to another more complicated

I know that in some issues the maintainer has indicated that DRF's throttling is only a "business feature" and is not intended to be used as an anti-DOS measure, but there's a large space in between those two. A great example is credential-stuffing or other login brute-force attacks: The attacker's goal there is not a denial of service, and these attacks can be reasonably mitigated by per-IP throttling rules -- as long as the right IP is used and it is not spoofable.

Rather than further complicate DRF's IP determination, I'd suggest that DRF check for request.META['BEST_CLIENT_IP'] (or whatever) and use it if available. Then any application that wants to do something fancier can just set that key in an early middleware, and DRF doesn't have to know anything about the shape of the network at all. All of that complexity can be outsourced, and applications can use whatever approach is required to meet their security needs. (This would likely most commonly involve reading some CDN-specific headers.)

I'd be happy to make a PR implementing something like this.