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
Prefer placing throttles nearer to your vulnerable code, as they are less likely to be bypassed due to developer forgetfulness.
For example:
Developer protects all API v1 endpoints authentication from brute force attacks with a throttle in your rack attack initializer.
Developer introduces API v2 endpoints that use the same authentication code (User.authenticate) as API v1, but forgets to add a corresponding throttle to the rack attack initializer for the new endpoints.
API v2 is vulnerable to brute force attacks.
If the throttle had instead been placed in User.authenticate, then API v2 would have been protected from brute force attacks and developer forgetfulness.
Prefer placing throttles nearer to your vulnerable code, as they are less likely to be bypassed due to developer forgetfulness.
For example:
User.authenticate
) as API v1, but forgets to add a corresponding throttle to the rack attack initializer for the new endpoints.If the throttle had instead been placed in
User.authenticate
, then API v2 would have been protected from brute force attacks and developer forgetfulness.Relevant discussion and ideas for using rack attack throttles outside of the initializer: rubygems/rubygems.org#2088 (comment)
The text was updated successfully, but these errors were encountered: