You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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 aNUM_PROXIES
option which can be configured, but this has several downsides.Downsides of
NUM_PROXIES
: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.
Beta Was this translation helpful? Give feedback.
All reactions