Rate Limit Fail-Closed Automation: A Limiter That Could Not See Was Letting Everything Through

A rate limiter's entire function depends on two things being reliably true: knowing who a request should be attributed to, and knowing accurately how many recent attempts that same attribution has already produced. Whenever either of those two things becomes uncertain — the identifier cannot be determined, or the count itself could not be retrieved — a limiter has, in the moment of genuine uncertainty, LESS basis for confidence that a request is legitimate, not more. A design that responds to exactly that uncertainty by removing the limit entirely gets the direction of the correct response backward: the situations where a limiter knows the least about what it is looking at are precisely the situations where erring toward caution matters most, because they are also the situations most likely to be produced deliberately by whoever is trying to defeat the limiter in the first place.

Handling a missing identifier or a failed measurement by explicitly refusing the request requires a deliberate, additional branch of logic — a specific decision that uncertainty should be treated as a reason for caution. Handling the identical situation by falling through to a default that happens to allow the request requires no such deliberate decision at all; it is frequently just what already happens when a piece of code has nothing concrete to act on, or when a fallback value like `?? 0` is used purely for type-safety convenience rather than as a considered security decision. The gap opens specifically because the EASIEST way to write code that tolerates a missing identifier or a failed query, without crashing outright, happens to also be the LEAST safe way to handle the identical situation from a security standpoint — and nothing about writing the easier version produces any visible symptom to signal that a more deliberate choice was actually needed.

Centriu Loop's own rate-limiting function checks a request's recent activity against a configured threshold before allowing an action like opening a balance session or recording a movement to proceed. Two separate, genuinely distinct situations inside that function previously defaulted to allowing the request through with no limit applied, confirmed directly from the prior code's own logic.

The first triggered whenever the function could not determine an identifier — typically a caller's IP address — to measure the request against at all. The prior code's own response, in that case, was to return an unconditional `allowed: true`, on the reasoning that with no identifier to attribute the request to, there was nothing meaningful left to check against a threshold. The fix reverses this outright: a missing identifier now returns an explicit, unconditional denial, on the equally direct reasoning that a limiter with no way to attribute a request has, if anything, LESS basis to trust it, not a reason to skip checking it altogether.

The second, entirely separate situation lived inside the function actually counting how many recent attempts had already occurred, most often as a database query. The prior code read the query's own result with a plain `count ?? 0` fallback — meaning that if the underlying query FAILED for any reason (a database hiccup, a network timeout, a genuine outage), the resulting `undefined` was silently converted to a count of exactly zero, a value that is always comfortably under any real threshold. A request arriving during exactly the moment the limiter's own measurement infrastructure was struggling would therefore be treated identically to a request the limiter had genuinely checked and found no concerning recent activity for — the two situations are completely different in what they actually tell you, and the prior code could not distinguish between them at all. The fix wraps the counting call in an explicit error boundary and returns an unconditional denial specifically when that call fails, rather than allowing an untrustworthy zero to stand in for a genuine measurement.

A third, related hardening in the same fix narrows exactly which header the function trusts when determining a caller's own IP address in the first place: the function now reads exclusively from a header Centriu's own reverse proxy sets directly (never forwarded or overridable by a client's own request), falling back only to the first entry of a second, less-trusted header when the primary one is genuinely absent — and returning no identifier at all, rather than an empty string, when neither is present, so that the newly fail-closed identifier-missing path is actually reached correctly rather than silently matching an empty value by accident.

Before the fix, a bouncer whose guest-list terminal froze or crashed responded by waving every arrival straight through, reasoning that with no working list to check, there was nothing left to verify against. After the fix, the identical frozen terminal results in nobody being admitted until it is working again — because a broken check is not the same fact as a genuine, checked "clear," and treating the two as identical defeats the entire purpose of having a check in the first place.

Centriu Loop's rate limiter now explicitly denies a request whenever it cannot identify the caller or whenever its own underlying counting mechanism fails, closing two separate paths where the prior code had silently defaulted to allowing every request through with no limit applied at all.

This automation covers specifically how Centriu Loop's rate limiter behaves under its own uncertainty — a missing identifier or a failed count. It is a distinct layer from this pillar's separate pages on Centriu Loop's session identity verification and permission default-deny fixes, and from wave 66's separate consumer-portal rate-limiter ATOMICITY fix — that page addresses a race condition in how concurrent requests are COUNTED; this page addresses what the SAME broader limiter does when it cannot count or identify a request at all.

Responding to a missing identifier or a failed measurement by allowing the request through avoids ever blocking a legitimate user during an infrastructure hiccup, which is a genuinely real, if narrow, concern. It does so specifically by removing the limiter's own protection during exactly the moments its own confidence is lowest — which, for a control whose entire purpose is resisting deliberate abuse, is the wrong moment to relax. Explicitly denying under the identical uncertainty accepts a narrow, honest cost (a legitimate request occasionally refused during a genuine infrastructure failure, with a clear, explicit error rather than a silent pass-through) in exchange for never leaving the limiter's own blind spot open to whoever might be causing that exact uncertainty on purpose.