Implementing Rate Limiting

Welcome to the very first lesson of the "implementing rate limiting" course! 🚀

In this lesson, we'll explore one of the most fundamental yet powerful security mechanisms in modern API development: rate limiting. Whether you're building a small web service or a large-scale API, understanding and implementing rate limiting is essential for protecting your application from abuse, managing resources efficiently, and ensuring fair access for all users.

By the end of this lesson, you'll have a working implementation of a global rate limiter protecting all your API endpoints. You'll understand not just the "how" but also the "why" behind this critical security feature. Let's dive in! 🎉

Rate limiting is a defensive strategy that controls how many requests a client can make to your API within a specified time period. Think of it as a bouncer at a club, keeping track of how many times someone tries to enter and enforcing the house rules.

Each client is identified by some unique characteristic — typically an IP address, but it could also be an API key, user ID, or other identifiers. When a client reaches their allotted number of requests within the time window, the rate limiter steps in and blocks subsequent requests until the time period resets.

For example, you might configure your API to allow each client:

• No more than 5 requests per minute for testing purposes.
• No more than 100 requests per hour for standard users.
• No more than 1000 requests per day for premium accounts.

These limits act as guardrails, protecting both your infrastructure and your users from problematic behavior.

Rate limiting isn't just about saying "no" to excessive requests — it's a multifaceted security and performance tool that provides several critical benefits:

Prevents server overload — Your server has finite resources: CPU cycles, memory, database connections, and network bandwidth. Rate limiting ensures that these resources aren't exhausted by a flood of requests, keeping your service responsive for all users.

Defends against DoS attacks — Distributed Denial of Service attacks attempt to overwhelm your API with massive volumes of requests. While rate limiting won't stop sophisticated DDoS attacks entirely, it significantly raises the bar for attackers and protects against simpler flooding attempts.

Ensures fair usage — Without rate limiting, a single aggressive client could monopolize your API, degrading service quality for everyone else. Rate limits create a level playing field where all clients get their fair share of resources.

Manages traffic spikes — Legitimate traffic can spike unexpectedly — a viral post, a marketing campaign, or a sudden surge in popularity. Rate limiting helps smooth out these spikes, preventing your infrastructure from buckling under sudden load.

Reduces costs — Many cloud services charge based on resource consumption: API calls to third-party services, database queries, or compute time. By limiting excessive usage, you also limit your operational costs.

Understanding where rate limiting happens in your application's request flow is crucial for effective implementation. In ASP.NET Core, rate limiters work as part of the middleware pipeline — a chain of components that process each incoming HTTP request.

Here's how the middleware pipeline works:

1. Sequential execution — Middleware components are executed in the exact order they're added to the IApplicationBuilder in your Program.cs file.

2. Request processing — Each middleware can inspect and modify the incoming request, perform authentication, logging, or other cross-cutting concerns.

3. Pipeline control — Middleware decides whether to pass the request to the next component (next()) or short-circuit the pipeline and return a response immediately.

4. Rate limiting interception — When properly configured, the rate limiting middleware sits early in this pipeline, checking each request against the client's rate limit before expensive operations occur.

5. Quick rejection — If a client has exceeded their limit, the middleware responds with a 429 Too Many Requests status code and stops processing, never reaching your controllers or business logic.

This architecture is elegant because it allows rate limiters to protect your application before any resource-intensive work begins — before database queries, before complex calculations, before external API calls.

Let's examine our application's starting point. Right now, we have a basic ASP.NET Core API with no rate limiting whatsoever. Here's our Program.cs:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/api/snippets/test-rate-limit", () =>
    Results.Ok(new { message = "This endpoint is just for testing rate limiting" })
);

app.Run();

This minimal configuration maps routes directly in Program.cs using ASP.NET Core's minimal API style, but provides zero protection against request flooding.

Our application includes a test endpoint for verifying rate limiting behavior:

app.MapGet("/api/snippets/test-rate-limit", () =>
    Results.Ok(new { message = "This endpoint is just for testing rate limiting" })
);

We also have an authentication route ready for future use:

// Auth endpoints would be mapped here
// app.MapPost("/api/auth/login", ...);

Without any rate limiting, these endpoints are completely vulnerable to abuse. An attacker could bombard them with thousands of requests, potentially overwhelming your server.

Without rate limiting, your API is an open target. Consider how easily an attacker could exploit this vulnerability:

# A simple attack using curl in a loop
for i in {1..100}; do
  curl http://localhost:5000/api/snippets/test-rate-limit
done

This basic script sends 100 requests in rapid succession. Now imagine scaling this up — thousands of requests per second from multiple machines. Even if each individual request is lightweight, the cumulative effect can:

• Exhaust server resources — CPU, memory, and network connections all have limits.
• Degrade database performance — If your endpoints query a database, you could overwhelm it with connections.
• Trigger cascading failures — Overloaded services often fail unpredictably, causing ripple effects throughout your system.
• Inflate costs — Cloud providers charge for resource usage, and an attack could result in an unexpectedly large bill.

The solution? Let's implement rate limiting to stop these attacks before they cause damage.

ASP.NET Core 7.0 and later versions include powerful built-in rate limiting capabilities, eliminating the need for third-party libraries. The first step is registering the rate limiting services with your application's dependency injection container.

Add this to your Program.cs before building the app:

builder.Services.AddRateLimiter(options =>
{
    // We'll configure the limiter here in the next step
});

This single method call does several things behind the scenes:

• Registers the rate limiter services with the DI container.
• Prepares the infrastructure for tracking request counts per client.
• Sets up the foundation for the middleware we'll add later.

Now we're ready to configure how our rate limiting will actually work.

With the services registered, we need to define our rate limiting policy. We'll use a fixed window limiter, which divides time into discrete windows and tracks requests within each window.

Instead of creating a named policy that must be explicitly applied to each route, we'll assign our limiter to the GlobalLimiter property. This approach automatically applies rate limiting to every request without requiring any per-route configuration.

Add this configuration inside the AddRateLimiter call:

using System.Threading.RateLimiting;

builder.Services.AddRateLimiter(options =>
{
    options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(httpContext =>
    {
        var ip = httpContext.Connection.RemoteIpAddress?.ToString() ?? "unknown";
        return RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: ip,
            factory: _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = 5,
                Window = TimeSpan.FromSeconds(30),
                QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                QueueLimit = 0
            });
    });

    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
});

Let's break down each part of this configuration:

GlobalLimiter — Unlike a named policy that requires explicit opt-in per route, GlobalLimiter intercepts every incoming request before it reaches any route handler. It acts as a global checkpoint for the entire application.

PartitionedRateLimiter.Create — This creates a rate limiter that maintains separate counters for different clients. Each client gets their own independent counter, so one client hitting their limit doesn't affect anyone else.

Partition key (IP address) — We identify each client by their IP address using httpContext.Connection.RemoteIpAddress. The ?? "unknown" fallback handles edge cases where the address can't be determined.

RateLimitPartition.GetFixedWindowLimiter — This instructs the partitioned limiter to use the fixed window algorithm for each partition, giving every unique IP address its own fixed window counter.

FixedWindowRateLimiterOptions — This is where we configure the actual limit rules:

• PermitLimit — The maximum number of requests allowed per client during the window (5 requests). Once reached, additional requests are rejected.
• Window — The duration of our time window (30 seconds). When a new window starts, the request count resets to zero for each client.
• QueueProcessingOrder — If we allowed queuing (we don't in this case), this would determine the order requests are processed from the queue. OldestFirst means first-come, first-served.
• QueueLimit — Setting this to 0 means we won't queue any requests that exceed the limit. They're rejected immediately.

RejectionStatusCode — When a request is rejected, we'll return HTTP status 429 Too Many Requests, which is the standard code for rate limiting.

Now that we've configured our rate limiting policy, we need to activate the middleware that will enforce it. Middleware order matters in ASP.NET Core, so we'll add the rate limiter before we map our routes.

Add these lines to your Program.cs:

var app = builder.Build();

app.UseRateLimiter();

app.MapGet("/api/snippets/test-rate-limit", () =>
    Results.Ok(new { message = "This endpoint is just for testing rate limiting" })
);

app.Run();

The UseRateLimiter() method inserts the rate limiting middleware into your request pipeline. Because we've configured a GlobalLimiter, the middleware will automatically apply our rate limiting policy to every incoming request, regardless of which route it targets.

With the GlobalLimiter in place, there's nothing more to configure here — the policy is already applied to all endpoints automatically. Every request that passes through UseRateLimiter() is checked against our global limit, with no need to annotate individual routes.

This is a key advantage of GlobalLimiter over named policies. A named policy approach would require explicit opt-in on every route:

// Named policy approach (NOT what we're using) — requires explicit opt-in per route
app.MapGet("/api/snippets/test-rate-limit", ...).RequireRateLimiting("globalLimit");

With GlobalLimiter, you can never accidentally leave a new endpoint unprotected simply by forgetting to attach a policy.

Here's how the complete Program.cs looks with all our changes:

using System.Threading.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRateLimiter(options =>
{
    options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(httpContext =>
    {
        var ip = httpContext.Connection.RemoteIpAddress?.ToString() ?? "unknown";
        return RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: ip,
            factory: _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = 5,
                Window = TimeSpan.FromSeconds(30),
                QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                QueueLimit = 0
            });
    });

    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
});

var app = builder.Build();

app.UseRateLimiter();

app.MapGet("/api/snippets/test-rate-limit", () =>
    Results.Ok(new { message = "This endpoint is just for testing rate limiting" })
);

app.Run();

With this configuration in place, every endpoint is now protected by our rate limiter. Let's verify it works.

Testing is crucial to ensure our rate limiter behaves as expected. We'll create a simple C# console application that sends multiple requests to our test endpoint.

Create a new console project and add this code:

using System.Net.Http;

var client = new HttpClient();
Console.WriteLine("Testing global rate limit...\n");

for (int i = 1; i <= 10; i++)
{
    try
    {
        var response = await client.GetAsync("http://localhost:5000/api/snippets/test-rate-limit");
        
        if (response.IsSuccessStatusCode)
        {
            Console.WriteLine($"Request {i}: {(int)response.StatusCode} Success");
        }
        else
        {
            var content = await response.Content.ReadAsStringAsync();
            Console.WriteLine($"Request {i}: {(int)response.StatusCode} {content}");
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine($"Request {i} failed: {ex.Message}");
    }
    
    await Task.Delay(10);
}

This script sends 10 requests with a tiny delay between them. When you run it, you should see output like this:

Testing global rate limit...

Request 1: 200 Success
Request 2: 200 Success
Request 3: 200 Success
Request 4: 200 Success
Request 5: 200 Success
Request 6: 429 Too many requests
Request 7: 429 Too many requests
Request 8: 429 Too many requests
Request 9: 429 Too many requests
Request 10: 429 Too many requests

Perfect! The first five requests succeed, and the rest are rejected with 429 status codes. Our rate limiter is working exactly as configured.

Important note: Your actual output may vary slightly depending on timing factors. System delays, network latency, or longer gaps between requests can affect when the rate limit kicks in. The key pattern to observe is that after approximately 5 successful requests, you should consistently see 429 responses.

Congratulations! You've just implemented a robust global rate limiter that protects all your API endpoints from abuse. Let's reflect on what we've built and why it matters.

With just a few strategic additions to Program.cs, we've transformed our vulnerable API into one that can withstand basic flooding attacks. Our rate limiter now:

• Tracks requests per client automatically.
• Enforces our 5 requests per 30 seconds limit consistently.
• Responds with appropriate HTTP status codes when limits are exceeded.
• Protects all endpoints without requiring per-endpoint configuration.

This is a significant security improvement, but it's also just the beginning. As you might have noticed, our global rate limiter treats all endpoints and all clients the same way. In real-world applications, you'll often need more nuance:

Different limits for different endpoints — Your authentication endpoint might need stricter limits than a public read-only endpoint.

User-based rate limiting — Premium users might get higher limits than free-tier users.

More sophisticated algorithms — Fixed windows can have edge cases; sliding window or token bucket algorithms might be better for your use case.

Dynamic limits — Adjust limits based on current server load or time of day.

In upcoming lessons, we'll explore these advanced scenarios, learning how to:

• Apply different rate limiting policies to specific routes or endpoints.
• Create specialized limiters for authentication endpoints with stricter rules.
• Implement sliding window and token bucket algorithms for smoother rate limiting.
• Use partition keys to apply different limits based on user roles, API keys, or other criteria.
• Handle rate limiting in distributed systems with multiple servers.

Rate limiting is a fundamental building block of API security, but it's most effective when combined with other security measures like authentication, authorization, input validation, and monitoring. Together, these practices create a defense-in-depth strategy that keeps your application secure and performant.

In the next lesson, we'll take our rate limiting to the next level by learning how to apply different limits to different parts of your API. See you there! 🚀