The arithmetic turns this from a weakness into a hole. A throttle permits some number of attempts per bucket per window, and the number of buckets is the number of distinct keys the counter has seen. When the key comes out of a request header, the client picks how many distinct keys exist [3]. Total attempts allowed is the per-bucket limit multiplied by a count the attacker chooses, which means there is no ceiling [1]. Each bucket stays under its limit, so the graph you would use to notice credential stuffing reads healthy [4].
The socket peer address is a different kind of value. It is the address the connection was actually accepted from, and forging it requires controlling it [5]. Nothing in the request body or headers can move it.
Whether you copy the trade depends on what sits in front of your listener. The post names the cost plainly: behind a reverse proxy every request arrives from the proxy's address, so the limit applies to the proxy rather than per client [6]. If one proxy or one CDN edge terminates every connection you serve, the peer address is effectively constant, and a per-client limit becomes a per-deployment limit that one determined client can drain for everybody else [6]. That is a tolerable trade for Tessera, a controller whose users are operators registering targets in an admin UI [9]. It is a poor one for a consumer login page behind shared edge infrastructure.
For that case the post gives the right answer rather than the convenient one: an explicit allowlist of trusted proxy addresses whose forwarded headers you accept, instead of blanket trust of the header [8]. That keeps per-client granularity and makes the trust boundary a config value you can read. It also makes the trust boundary a config value you have to maintain, which is the part that rots quietly when the proxy fleet changes.
The same shape shows up in the next decision in the same write-up. Target hosts are validated on creation and on update, because validate-on-create with an unchecked update path is a common way to carry the bug while believing it is fixed [10]. Both cases share the same defect: a control exists, it reports success, and the party it was written to constrain can bypass it [2].
Worth being clear about the evidence. This is one engineer writing up decisions in a product they work on, disclosed as such, with no measurement attached and nothing to reproduce [1]. The reason it transfers anyway is that the claim is checkable without any of their code. Read the line in your own limiter that computes the key, and see who controls the value it reads. If that value came from a header, the fix is a field lookup on the connection, and the argument you will then have with your own topology is the one the post already had.
The wider point in the same piece is that security feature lists are made of nouns, and the details that decide whether the system holds are smaller than any noun on the list [13]. "We rate limit the login endpoint" is a noun.
