Welcome back to our course on implementing rate limiting! 🚀

In the previous lesson, we implemented a global rate limiter to protect our entire API against potential DoS attacks. While this provided solid foundational protection, a one-size-fits-all approach doesn't meet the diverse needs of different endpoints as your application grows.

Consider this scenario: your authentication endpoint handles sensitive login attempts that could be targeted by brute-force attacks, while your public data endpoint serves lightweight read operations. Applying the same rate limit to both doesn't make sense. The authentication endpoint needs stricter controls, while the data endpoint can afford more generous limits.

By the end of this lesson, you'll understand how to implement customized rate limits for individual endpoints in your ASP.NET Core REST API, giving you fine-grained control over your application's traffic management. Let's dive in! 🎉

Endpoint-specific rate limiting allows you to apply different rate limiting rules to different API endpoints based on their sensitivity, resource requirements, and business importance. Rather than treating all endpoints equally, this approach recognizes that each endpoint has unique characteristics that warrant customized protection.

Think of it like security at a large building. The main entrance might allow hundreds of visitors per hour, but access to the server room is restricted to a handful of authorized personnel. Similarly, your API endpoints have varying levels of sensitivity and should be protected accordingly.

There are several compelling reasons to implement endpoint-specific limits. First, it provides tailored protection by applying stricter limits to sensitive operations like user authentication or financial transactions. Second, it enables optimized resource allocation by allowing more requests for lightweight endpoints that don't strain your infrastructure. Third, it creates an improved user experience by balancing security with accessibility, ensuring legitimate users aren't unnecessarily blocked from commonly used features.

Implementing endpoint-specific limits involves defining multiple named policies with different configurations and applying them to specific endpoints using the .RequireRateLimiting() method.

Understanding the mechanics behind ASP.NET Core's rate limiting helps you implement it more effectively. The rate limiting system works through the middleware pipeline, intercepting requests before they reach your endpoint handlers. This early interception means that rate-limited requests never consume the resources needed to execute your business logic.

For endpoint-specific limiting, we define multiple named policies during application configuration, each encapsulating its own set of rules. These policies are then applied to specific endpoints by chaining .RequireRateLimiting("policyName") on the endpoint definition.

When a request arrives at your API, ASP.NET Core's middleware pipeline processes it through the rate limiter in a systematic way. First, the middleware identifies which policy applies to the requested endpoint. Then, it checks whether the client has exceeded the allowed request quota for that specific policy. Finally, based on this evaluation, the middleware either forwards the request to the next middleware and eventually to the endpoint handler, or returns a 429 (Too Many Requests) response to indicate the limit has been exceeded.

This approach provides granular control over rate limiting rules while keeping your configuration clean and maintainable. Each endpoint can have its own policy, and changing limits for a specific endpoint doesn't affect others.

Let's examine our current minimal API endpoints to identify which ones need customized protection. Understanding the different resource requirements of each endpoint helps us make informed decisions about rate limiting.

Currently, we have a global rate limiter from the previous lesson applied to all API routes via app.UseRateLimiter() in our Program.cs file. However, examining these endpoints reveals different needs.

The POST /api/snippets endpoint creates new database records. This is a resource-intensive operation that involves validation, database writes, and potentially triggering other processes. Such operations should be more strictly limited to prevent database strain.

The GET /api/snippets/{id} endpoint only reads data from the database. This is a less intensive operation that can tolerate more requests since it doesn't modify state and can often benefit from caching.

Without endpoint-specific limits, our API faces several significant risks that could impact both security and user experience.

Resource exhaustion is a primary concern. A high volume of write operations could overwhelm the database, causing slowdowns or failures across your entire application. Even if you have a global limit, attackers could focus their requests on expensive operations.

Inefficient protection becomes apparent when you realize that the same limit for all endpoints means some are over-protected while others remain vulnerable. Your read endpoints might reject legitimate users while write endpoints still receive too many requests.

Poor user experience results when legitimate users hit limits too quickly on commonly used endpoints. If users frequently access your read endpoints but occasionally write data, a uniform limit penalizes normal usage patterns.

Consider an attacker rapidly creating new snippets. With only the global rate limiter in place, users might unnecessarily hit limits on read operations due to overall traffic, while your database could still be strained by a concentrated attack on write operations.

Now let's implement endpoint-specific rate limiters to provide customized protection. We'll approach this in three logical steps, starting with the basic configuration structure.

First, we need to set up the rate limiting framework in our Program.cs file. This establishes the foundation upon which we'll build our specific policies.

The AddRateLimiter method accepts an options object where we configure all our policies. The UseRateLimiter() call in the middleware pipeline ensures all requests pass through our rate limiting logic before reaching the endpoint handlers.

With our framework in place, we can now define separate policies for different types of operations. Each policy has a unique name that we'll reference later when applying it to endpoints.

The writeOperations policy allows only 5 requests per minute, reflecting the resource-intensive nature of create, update, and delete operations. The readOperations policy is more generous with 30 requests per minute, acknowledging that read operations are typically lighter on resources.

Setting QueueLimit to zero means requests exceeding the limit are immediately rejected rather than queued. This provides immediate feedback to clients and prevents memory consumption from growing queues.

When a request exceeds the rate limit, we want to provide helpful feedback to the client. This is configured within the same AddRateLimiter options block.

The OnRejected callback allows us to customize the response sent to clients when they exceed their limit. We set the HTTP status code to 429 (Too Many Requests) and include helpful information in the response body. When available, we include the retryAfter value so clients know how long to wait before trying again.

The final step is applying these policies to the appropriate endpoints by chaining .RequireRateLimiting() on each endpoint definition. This method takes the policy name as a parameter and tells the middleware which rules to apply.

Notice how each endpoint has .RequireRateLimiting() chained with the appropriate policy name. The POST and DELETE operations use the stricter writeOperations policy, while GET operations use the more relaxed readOperations policy.

This approach makes it easy to see at a glance which rate limiting policy applies to each endpoint. The middleware checks the policy associated with the requested endpoint and applies the corresponding rules before the handler executes, ensuring rate-limited requests never reach your business logic.

To verify your endpoint-specific rate limiting is working correctly, you can create a simple C# console application that sends multiple requests to each endpoint type.

When you run this test application, you should see output similar to this:

This output clearly demonstrates that our endpoint-specific rate limiting is working as intended. The first 5 POST requests succeed with status code 200 (OK), showing that our writeOperations policy is allowing the configured 5 requests per minute. The 6th request receives status code 429 (Too Many Requests), indicating the limit has been exceeded and the rate limiter is rejecting additional requests.

Similarly, the GET requests demonstrate the more relaxed readOperations policy in action. The first 30 requests all succeed with 200 status codes, confirming that our read endpoint allows 30 requests per minute. Only the 31st request hits the limit and receives the response.

Endpoint-specific rate limiting is crucial in production applications for several important reasons.

• Authentication endpoints need stricter limits to prevent brute-force attacks. A malicious actor trying to guess passwords should be limited to just a few attempts before being blocked.

• Resource-intensive operations like file uploads or complex database writes should be limited to prevent resource exhaustion. Even legitimate heavy usage could overwhelm your infrastructure without proper limits.

• Public endpoints serving cached or static data might need more relaxed limits to accommodate legitimate traffic from many users simultaneously.

A typical production API might implement these rate limit tiers as a starting point. Login and registration endpoints might allow 5-10 requests per 5 minutes. Database write operations could permit 60 requests per minute. Database read operations might allow 300 requests per minute. Public, cacheable data endpoints could handle 1000 requests per minute.

These numbers should be adjusted based on your specific infrastructure capacity, user behavior patterns, and security requirements. Monitoring actual usage helps you fine-tune these limits over time.

In this lesson, we've explored how to implement endpoint-specific rate limits in our ASP.NET Core REST API. By defining multiple named policies and applying them using .RequireRateLimiting(), we've created a more nuanced security layer that protects resource-intensive operations while maintaining accessibility for less demanding requests.

The key concepts we covered include understanding why different endpoints have different needs, defining separate rate limiter policies for different operations, applying these policies to individual endpoints using the .RequireRateLimiting() method, and understanding how ASP.NET Core's middleware pipeline processes these policies.

Effective API security involves multiple layers of protection, and endpoint-specific rate limiting is an essential component of a comprehensive security strategy. In the upcoming practice exercises, you'll have the opportunity to implement these concepts hands-on and experiment with different configurations to solidify your understanding.