Rate Limiting in ASP.NET Core: Protect Your API

A single client, meaning no harm at all, can take down a shared resource just as effectively as an attacker — rate limiting is the guardrail either way.

Imagine your API's /api/search endpoint calls a paid, rate-limited third-party mapping service on every request. One day, a single legitimate client — no malicious intent whatsoever, just a bug in their retry logic — starts firing thousands of requests a second. Your API happily accepts every one of them and forwards each to the mapping service, which promptly rate-limits you, breaks search for every other customer, and hands you a surprise bill. Nothing about this required an attacker. A perfectly well-behaved client with a bug was enough.

Now widen the picture: a genuine attacker deliberately hammering a login endpoint to brute-force passwords, or a script scraping your entire product catalog in seconds, or simply far more traffic from one client than your database can comfortably serve while still being fair to everyone else. All of these are the same underlying problem, wearing different hats: too many requests, from one source, in too little time. Rate limiting is the mechanism that puts a boundary on that.

In this lesson: why APIs need rate limiting, ASP.NET Core's built-in Microsoft.AspNetCore.RateLimiting middleware (part of the framework since .NET 7), its four algorithms — Fixed Window, Sliding Window, Token Bucket, and the Concurrency Limiter — with their genuine trade-offs, and how to configure and apply a policy to real endpoints.

What Is It?

The Simple Explanation

Rate limiting is capping how many requests a client is allowed to make in a given period of time (or how many it can have in flight at once), and rejecting — usually with an HTTP 429 Too Many Requests — whatever exceeds that cap.

The Technical Definition

ASP.NET Core ships a built-in rate limiting middleware, Microsoft.AspNetCore.RateLimiting, available since .NET 7. It's configured with one or more named rate limiter policies — each backed by one of four built-in algorithms (Fixed Window, Sliding Window, Token Bucket, or Concurrency) — registered once via AddRateLimiter(), then applied to specific endpoints or endpoint groups. A request that violates its policy's limit is rejected before reaching your endpoint logic at all, with a configurable response (429 by default).

Why Does It Exist?

The Problem — Unlimited Traffic Hurts Everyone Sharing the System

An API without any rate limiting treats every client as if it could send unlimited traffic without consequence. In practice, that assumption breaks down in three genuinely distinct ways:

• Abuse — an attacker deliberately sending excessive traffic: brute-forcing a login form, scraping data at high speed, or attempting a denial-of-service.
• Unfairness — one client, even without malicious intent, consuming so much capacity that every other client sharing the same API suffers degraded performance.
• Downstream overload — even entirely legitimate, well-intentioned traffic can overwhelm a shared, finite resource behind your API: a database that can only handle so many concurrent queries, or a paid third-party API with its own rate limits and per-call costs, exactly as in the hook.

The Need

What's needed is a way to cap how much traffic any single client can generate — configurable per endpoint, since a login endpoint and a static content endpoint have very different reasonable limits — enforced consistently and cheaply, before that traffic ever reaches the expensive parts of the system.

The Solution

ASP.NET Core's built-in rate limiting middleware, offering four different algorithms because "cap the traffic" is not actually one single problem — a login endpoint's needs (protect against brute-force bursts) are genuinely different from a background sync endpoint's needs (allow occasional bursts, enforce a steady average), and the four algorithms below exist specifically to match those different shapes of need.

Big Picture

How It Works

Simple Example

Registering a fixed window policy and applying it to one endpoint:

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("fixed", opt =>
    {
        opt.PermitLimit = 10;                          // up to 10 requests...
        opt.Window = TimeSpan.FromSeconds(30);         // ...per 30-second window
        opt.QueueLimit = 0;                             // requests over the limit are rejected immediately, not queued
    });

    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
});

var app = builder.Build();
app.UseRateLimiter(); // add the middleware to the pipeline

app.MapGet("/api/weather", () => Results.Ok(GetWeather()))
   .RequireRateLimiting("fixed"); // apply the named policy to this endpoint

Meaning: The policy is defined once, by name, and attached to whichever endpoints need it via RequireRateLimiting("fixed") — the same reusable-policy shape you've already seen for authorization policies, applied here to traffic instead of permissions.

Real-World Example

Different endpoints, genuinely different rate-limiting needs — matching each algorithm to the shape of the problem it actually solves:

builder.Services.AddRateLimiter(options =>
{
    // Login: protect against brute-force attempts, per client IP — a strict, simple cap is appropriate here.
    options.AddFixedWindowLimiter("login", opt =>
    {
        opt.PermitLimit = 5;
        opt.Window = TimeSpan.FromMinutes(1);
    });

    // General API traffic: allow normal bursts of activity (a user rapidly paging through results)
    // while still holding everyone to a fair, steady average rate.
    options.AddTokenBucketLimiter("api", opt =>
    {
        opt.TokenLimit = 20;                              // bucket capacity — allows a burst of 20
        opt.TokensPerPeriod = 5;
        opt.ReplenishmentPeriod = TimeSpan.FromSeconds(10); // refills 5 tokens every 10 seconds
    });

    // Report generation: expensive, resource-heavy work — the concern isn't request volume over time,
    // it's how many of these can genuinely run AT ONCE without overwhelming the reporting engine.
    options.AddConcurrencyLimiter("reports", opt =>
    {
        opt.PermitLimit = 3;   // at most 3 report generations in flight simultaneously, from anyone
        opt.QueueLimit = 10;   // additional requests wait in a queue rather than being rejected outright
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    });

    options.OnRejected = async (context, token) =>
    {
        context.HttpContext.Response.StatusCode = StatusCodes.Status429TooManyRequests;
        await context.HttpContext.Response.WriteAsync("Too many requests — please slow down.", token);
    };
});

app.UseRateLimiter();

app.MapPost("/api/login", LoginHandler).RequireRateLimiting("login");
app.MapGet("/api/products", GetProducts).RequireRateLimiting("api");
app.MapPost("/api/reports/generate", GenerateReport).RequireRateLimiting("reports");

Three different policies, three different algorithms, because each endpoint's actual risk is genuinely different: login needs strict, simple abuse protection (Fixed Window); everyday API browsing needs to tolerate normal bursty usage while staying fair overall (Token Bucket); expensive report generation needs to cap simultaneous load on a shared resource, regardless of how spread out over time the requests are (Concurrency Limiter).

Analogy

Under the Hood

Common Confusion

1. "Rate limiting is only about stopping attackers" — no, fairness and downstream protection matter just as much

It's tempting to think of rate limiting purely as a security feature against malicious traffic. As the hook illustrated, entirely well-intentioned clients can just as easily overwhelm a shared resource through a bug, an unexpectedly popular feature, or simple scale. Rate limiting protects the system's overall health and fairness, independent of anyone's intent.

2. "A rate limit over time and a concurrency limit are the same idea" — they measure genuinely different things

A time-based limit (fixed window, sliding window, token bucket) asks "how many requests happened in this period?" A concurrency limit asks "how many requests are actively in progress right now?" A client sending requests one-at-a-time, waiting for each to finish before sending the next, could never trip a concurrency limiter no matter how many total requests it sends over a day — but it could easily trip a strict fixed-window limit if it sends them fast enough within one window. These are answering different questions, and picking the wrong one for a given problem (protecting a limited connection pool vs. protecting against a chatty client) won't actually solve it.

Common Mistakes

Mistake 1 — Applying one global limit shared by every client

A single fixed-window policy with no partition key, meaning one aggressive client can exhaust the entire limit and lock out every other legitimate client sharing it.

Partition the limiter by client IP or authenticated user ID, so each caller gets its own independent budget.

Mistake 2 — Using Fixed Window where boundary bursts genuinely matter

Protecting a genuinely fragile downstream resource (a strict third-party rate limit) with Fixed Window, not accounting for the possibility of nearly double the configured rate landing right at a window boundary.

Use Sliding Window (or a sufficiently conservative Token Bucket configuration) when the boundary-burst behavior would actually cause a real problem for what's being protected.

Mistake 3 — Reaching for a time-based limiter to protect against simultaneous load

Using a Token Bucket policy to try to cap how many report generations can run at once, when the actual risk is overwhelming the reporting engine with too much concurrent work — a slow, spread-out trickle of requests could still pass a time-based limit while still overloading the engine if enough of them land at once.

Use the Concurrency Limiter specifically when the concern is simultaneous in-flight load on a resource, not total volume over a time window.

When Should I Use It?

• Use Fixed Window for simple, strict caps where the boundary-burst behavior is an acceptable trade-off for simplicity — a reasonable default for endpoints like login where "at most N per minute" is a fine approximation.
• Use Sliding Window when the boundary-burst problem genuinely matters — protecting a resource with a hard, strict external limit that a brief 2x spike would actually violate.
• Use Token Bucket as a general-purpose default for everyday API traffic, when tolerating short, normal bursts (a user quickly paging through results) while still holding to a fair long-run average is the goal.
• Use the Concurrency Limiter when the real concern is simultaneous load on a specific resource (a database connection pool, an expensive computation engine) rather than total request volume over time.
• Don't apply the same blanket rate limit to every endpoint — a public, cheap read endpoint and an expensive write or authentication endpoint have genuinely different, reasonable limits.

Mental Model

Key Takeaway

Check Your Understanding

You've seen why APIs need rate limiting and how each of the four built-in algorithms handles the problem differently. Let's check your understanding.

You now know how to protect your API — and everything behind it — from excessive traffic, whether it comes from an attacker, a bug, or simply more legitimate demand than one client should fairly consume.