// the find
stefanprodan/AspNetCoreRateLimit
ASP.NET Core rate limiting middleware
Rate limiting middleware for ASP.NET Core that lets you cap requests by IP or client ID, with per-endpoint and per-verb granularity. It predates .NET 7's built-in rate limiting and filled a real gap in its time. Today it's in maintenance mode — the author pinned an issue pointing to the native alternative.
Rule-based matching is flexible: you can mix wildcard endpoint patterns with specific HTTP verbs and set independent counters per combination. The pluggable store model (IMemoryCache or IDistributedCache, with a Redis package for the latter) means you can start in-process and switch to distributed without rewriting configuration. Runtime policy updates — changing limits without restarting the app — are supported via the policy store API, which the built-in .NET middleware still doesn't offer as cleanly. The resolve-contributor pattern for extracting client identity is genuinely extensible.
The project is effectively unmaintained — last meaningful commit was years before the 2024 push, and .NET 7+ ships System.Threading.RateLimiting with token bucket, sliding window, and concurrency limiters natively. The counter store implementations use IDistributedCache which serializes to JSON, so high-traffic scenarios will feel the overhead. There are no built-in headers for communicating remaining quota (RateLimit-Remaining etc.) in the RFC-compliant format that clients actually expect. IP-based limiting behind a reverse proxy is a footgun: you have to manually configure which X-Forwarded-For headers to trust, and getting it wrong means all traffic looks like one client.