ASP.NET Core middleware for IP and client-based rate limiting to protect Web APIs and MVC apps.
AspNetCoreRateLimit is an open-source rate limiting middleware for ASP.NET Core that controls the rate of incoming requests to Web APIs or MVC applications. It helps prevent abuse, manage traffic loads, and ensure fair resource usage by enforcing limits based on IP addresses or client IDs. The middleware supports configurable rules for different time intervals and request scopes, making it adaptable to various security and performance needs.
ASP.NET Core developers building Web APIs, MVC applications, or microservices that require request throttling to protect against denial-of-service attacks, manage API quotas, or comply with usage policies.
Developers choose AspNetCoreRateLimit for its flexibility, extensibility, and seamless integration with ASP.NET Core's middleware pipeline. It offers granular control over rate limiting rules, supports distributed scenarios with Redis, and allows runtime updates, making it a robust alternative to built-in .NET rate limiting for complex use cases.
ASP.NET Core rate limiting middleware
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 defining multiple limits per time interval (e.g., second, minute) and scoping to specific endpoints or HTTP verbs, as detailed in the rule configuration wiki.
Optional Redis integration enables shared counters across server instances for consistent throttling in scalable applications, per the advanced configuration wiki.
Rate limit rules can be modified at runtime without restarting the app, supporting real-time adjustments as documented in the update sections.
Full customization of quota-exceeded responses, including status codes and messages, to match API standards, detailed in the quota exceeded response wiki.
Requires manual setup in Startup.cs and complex rule definitions in appsettings.json, which can be daunting compared to simpler built-in options.
Only natively supports IP and client ID; extending to other factors like request headers or business logic requires custom implementation via resolve contributors.
Major updates like v3.x.x introduce breaking changes that necessitate migration efforts, as warned in the version 3 breaking changes wiki.