Bits of .NET

⚙️ Your Rate Limiter Is Punishing an Entire Office for One User’s Traffic

ASP.NET Core’s built-in rate limiting keys its buckets by client IP address by default – which works fine until an entire company sits behind one corporate proxy or NAT gateway, and every employee’s request counts against the SAME bucket, so one person running a busy script gets a hundred coworkers throttled alongside them.

🔎 The Problem

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("api", opt =>
    {
        opt.PermitLimit = 100;
        opt.Window = TimeSpan.FromMinutes(1);
    });
});

app.MapGet("/api/data", () => Results.Ok(data))
   .RequireRateLimiting("api");

// Keyed only by IP (the default partition), every request from behind
// the same corporate NAT / proxy shares one 100-request-per-minute bucket -
// regardless of how many distinct human users are actually behind it.

✅ Fix: Partition by Something More Specific Than Raw IP

• If users are authenticated, key the limiter by user ID or API key instead of IP – `RateLimitPartition.GetFixedWindowLimiter(key: userId, …)` – so shared infrastructure doesn’t lump distinct accounts together.
• For anonymous traffic where IP is genuinely the only signal, consider a per-IP limit that’s generous enough to tolerate an office-sized burst, paired with a separate, stricter limit on a more specific key (session cookie, request fingerprint) to still catch actual abuse.
• A combination of both – user/API-key partitioning for authenticated calls, coarser IP-based limiting only as a backstop – avoids collapsing ‘one bad actor’ and ‘a hundred legitimate coworkers’ into the same bucket.

⚠️ How to Confirm This Is What’s Happening

• Log the `X-Forwarded-For` header (or whatever your proxy sets) alongside 429 responses – if many distinct forwarded IPs are converging on the same source IP hitting your rate limiter, that’s the shared-proxy signature.
• A support ticket describing ‘random users at [company] get logged out or blocked around the same time each day’ is a strong hint that the rate limiter’s partition key is too coarse for that traffic pattern.