Why do services split rate limiting into a pre-auth hook keyed by client address and a post-auth hook keyed by principal?

## Two limiters because there are two threats Rate limiting is usually discussed as one feature, but in a middleware chain it is naturally two hooks at two depths, because **the key a limiter can use is determined by what the chain has already established.** | Tier | Depth | Key | Protects | Typical budget | |---|---|---|---|---| | Coarse | outside authentication | client address or connection attribute | the credential check and everything cheap in front of it | generous, per address | | Fair-share | inside authentication | principal: account, tenant, API key | backend capacity and per-account fairness | tight, contractual | The coarse tier exists because verifying a credential is not free. Password verification is deliberately expensive, token verification involves signature checks and sometimes a lookup, and session validation usually touches a store. An attacker guessing credentials, or a broken client retrying in a tight loop, consumes exactly that work for every attempt. A limiter that only runs *after* authentication has, by definition, already paid for it — on every single rejected attempt. The fair-share tier exists because the limit the business actually promises is per identity: so many requests per minute per account, per tenant or per key. That limit cannot be stated before authentication, because nothing has established who is calling. ## Why one hook cannot cover both - **Placed before authentication**, a limiter has no principal. It can only count addresses, so it cannot state a quota, cannot isolate tenants, and cannot tell a paying customer's traffic from a scraper's. - **Placed after authentication**, a limiter never runs for a request that failed to authenticate — which is the traffic you most wanted to cap. Every failed attempt still costs a full credential verification. So the two are not redundancy; they are two different statements that happen to share a mechanism. ## Why address keys are weak, and what to do about it An address is a poor identity, and a candidate who says so has understood the tier: - many users share one address behind carrier-grade translation or a corporate egress, so a tight limit punishes everyone behind it; - one user's address changes as they move between networks, so a limit is easy to shed; - behind a proxy or load balancer, the immediate peer address is the proxy's; the client address comes from a forwarded header that is caller-controlled unless the hook is configured to trust only a known set of hops. The conclusions follow directly: keep the coarse tier **generous** — it is there to stop floods, not to be fair — and be explicit about where the address comes from. A limiter that reads a forwarded header without a trust rule can be bypassed by any client that sets it. ## Placement relative to the other hooks 1. **Inside the correlation-id hook**, so a rejection has an id. 2. **Inside the access-log and metrics hooks**, so every rejection is counted. A limiter placed outside them makes the one outcome you most need to see invisible: a client throttled all day looks like a client that went quiet. 3. **Inside the CORS hook**, so a browser preflight is answered rather than throttled into an opaque cross-origin failure. Counting preflights against a budget is a defensible choice; rejecting them is rarely what anyone intended. 4. **Outside the handler and outside any expensive parsing**, so a rejected request has consumed as little as possible. ## What the rejection should look like Both tiers answer with `429` and should include `Retry-After` so a well-behaved client knows when to come back rather than guessing. Keep the response body small and free of detail about the limit's internals. And keep the rejection cheap: a limiter that does expensive work in order to reject is a denial-of-service amplifier rather than a defence. ## Operating the pair - **Emit which tier rejected.** A `429` counter without a tier label cannot distinguish a flood from a customer exceeding their plan. - **Watch the coarse tier for collateral damage.** A sudden cluster of rejections from one address is often an office or a mobile carrier, not an attack. - **Roll out in observe-only first.** Count what would have been rejected before enforcing, on both tiers. - **Fail open or closed deliberately.** If the shared counter store is unavailable, the coarse tier usually fails open to avoid taking the service down with it, while a hard contractual quota may fail closed. Decide, write it down, and test it.