Rack middleware for blocking and throttling abusive requests in Ruby web applications.
Rack::Attack is a Rack middleware for Ruby web applications that protects against abusive clients by allowing developers to define rules for allowing, blocking, and throttling requests based on request properties. It helps mitigate security threats, performance degradation, and availability issues caused by malicious or poorly-behaved clients. The tool provides a flexible, reusable way to quickly mitigate abusive requests, reducing reliance on one-off hacks.
Ruby developers building Rails or Rack-based web applications who need to protect their apps from malicious traffic, such as login crackers, scrapers, or denial-of-service attacks. It is particularly useful for teams managing production applications that require configurable request filtering and rate limiting.
Developers choose Rack::Attack because it integrates seamlessly with Ruby web stacks as middleware, offering a programmatic and highly customizable approach to request filtering that complements lower-level protections like iptables or nginx. Its unique selling point is the combination of safelisting, blocklisting, throttling, and Fail2Ban/Allow2Ban patterns in a single, reusable gem, allowing fine-grained control over abusive traffic without requiring external infrastructure changes.
Rack middleware for blocking & throttling
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Allows developers to write custom Ruby blocks for safelisting, blocklisting, and throttling based on any request property, such as IP, path, or user agent, as shown in the README examples for login throttling and path blocking.
Integrates Fail2Ban and Allow2Ban patterns to automatically block or allow clients after repeated failures or successes, reducing manual intervention for persistent attackers, with configurable parameters like maxretry and bantime.
For Rails apps, it's enabled by default and configured via initializers, making setup straightforward without complex middleware plumbing, as detailed in the getting started section.
Supports customizable HTTP responses for blocked or throttled requests, including rate-limit headers like Retry-After, helping communicate limits to well-behaved clients, as explained in the customizing responses section.
Throttling and ban states require a shared cache store like Redis, adding infrastructure overhead and potential single points of failure; the README warns that in-memory stores are ineffective for multi-process deployments.
Developers must manually define and update rules to adapt to new threats, which can be error-prone and time-consuming compared to automated security services that update dynamically.
Each throttle check involves network roundtrips to cache servers, and having many rules can introduce latency, especially under high load, as acknowledged in the performance section of the README.