Rate limiting login and registration in a .NET 10 Minimal API (per IP, no extra packages)

#dotnet #csharp #security #webdev

The code lives in a public repo and is tested in CI.

This is part 3 of the series about my free, MIT-licensed .NET 10 Minimal API starter. In part 1 I covered the base template, and in part 2 I added per-user ownership of resources.

Today: protecting /register and /login from brute-force attempts with the rate limiter that ships with ASP.NET Core. No NuGet package needed.

What I wanted

Limit only the auth endpoints, not the whole API.
Limit per client IP, so one noisy client doesn't lock everyone out.
Return a proper 429 Too Many Requests with a Retry-After header and a ProblemDetails body.
Make the limits configurable from appsettings.json.
Keep the existing integration tests unaffected.

1. Options bound from configuration

public sealed class AuthRateLimitOptions
{
    public const string Section = "RateLimiting:Auth";
    public int PermitLimit { get; init; } = 5;     // requests allowed...
    public int WindowSeconds { get; init; } = 60;  // ...per window
}

This is a plain class that holds the two numbers. The defaults are 5 requests per 60 seconds, and anyone can override them in configuration.

2. The policy

public static class RateLimitingExtensions
{
    public const string AuthPolicy = "auth";

    public static IServiceCollection AddAuthRateLimiting(
        this IServiceCollection services, IConfiguration configuration)
    {
        var settings = configuration.GetSection(AuthRateLimitOptions.Section).Get<AuthRateLimitOptions>()
                       ?? new AuthRateLimitOptions();

        services.AddRateLimiter(options =>
        {
            options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

            options.AddPolicy(AuthPolicy, httpContext =>
                RateLimitPartition.GetFixedWindowLimiter(
                    httpContext.Connection.RemoteIpAddress?.ToString() ?? "unknown",
                    _ => new FixedWindowRateLimiterOptions
                    {
                        PermitLimit = settings.PermitLimit,
                        Window = TimeSpan.FromSeconds(settings.WindowSeconds),
                        QueueLimit = 0
                    }));

            options.OnRejected = async (context, ct) =>
            {
                if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retryAfter))
                {
                    context.HttpContext.Response.Headers.RetryAfter =
                        ((int)Math.Ceiling(retryAfter.TotalSeconds)).ToString(CultureInfo.InvariantCulture);
                }

                await context.HttpContext.Response.WriteAsJsonAsync(new ProblemDetails
                {
                    Status = StatusCodes.Status429TooManyRequests,
                    Title = "Too many requests. Try again later."
                }, ct);
            };
        });

        return services;
    }
}

What each piece does:

AddPolicy registers a named policy. Endpoints opt in by name, so everything else stays unlimited.
RateLimitPartition.GetFixedWindowLimiter creates one independent counter for each partition key. Using the IP as the key gives you one bucket per client.
QueueLimit = 0 means that excess requests get a 429 right away instead of waiting.
OnRejected sets the Retry-After header and writes a ProblemDetails response, so the error looks like every other error in the API.

3. Wiring it up

builder.Services.AddAuthRateLimiting(builder.Configuration);

// ...
app.UseHttpsRedirection();
app.UseRateLimiter();      // before authentication
app.UseAuthentication();
app.UseAuthorization();

Then I opt the two endpoints in:

group.MapPost("/register", Register)
    .AddEndpointFilter<ValidationFilter<RegisterRequest>>()
    .RequireRateLimiting(RateLimitingExtensions.AuthPolicy);

group.MapPost("/login", Login)
    .AddEndpointFilter<ValidationFilter<LoginRequest>>()
    .RequireRateLimiting(RateLimitingExtensions.AuthPolicy);

UseRateLimiter() goes before UseAuthentication() so that abusive requests are rejected before any password hashing happens.

4. Testing it without breaking the other tests

Every integration test calls /register and /login, so a limit of 5 per minute would make the whole suite flaky. My ApiFactory (the shared WebApplicationFactory) raises the limit:

builder.UseSetting("RateLimiting:Auth:PermitLimit", "1000");

A dedicated factory then lowers it to 3 for the one test that checks the limiter itself:

builder.UseSetting("RateLimiting:Auth:PermitLimit", "3");

[Fact]
public async Task Login_is_rate_limited_after_too_many_attempts()
{
    var body = new { email = "nobody@test.com", password = "Wrong1234!" };

    for (var i = 0; i < 3; i++)
    {
        var allowed = await _client.PostAsJsonAsync("/api/auth/login", body);
        Assert.Equal(HttpStatusCode.Unauthorized, allowed.StatusCode);
    }

    var blocked = await _client.PostAsJsonAsync("/api/auth/login", body);

    Assert.Equal(HttpStatusCode.TooManyRequests, blocked.StatusCode);
    Assert.NotNull(blocked.Headers.RetryAfter);
}

The tests run in CI like everything else, and I also checked the 429 by hand with the .http file.

Limitations

This setup is intentionally simple, and you should know where it stops:

Behind a reverse proxy (nginx, a cloud load balancer), RemoteIpAddress is the proxy's IP unless you configure UseForwardedHeaders. Otherwise all your users share one bucket.
The counters live in memory, per instance. If you scale to several instances, each one counts separately. For that you'd need a distributed approach (e.g. Redis).
It limits by IP, not by account. Someone spreading attempts across many IPs is not stopped. A per-account lockout is on my list.

Try it

Next up: a /health endpoint that checks the database, and refresh tokens. If you have feedback or want something covered, open a Discussion.

DEV Community