What rate limiting is

Rate limiting is a cap on how many requests are allowed in a period of time. RFC 6585 (April 2012) introduces status 429 Too Many Requests for this: the user has sent too many requests in a given amount of time. The response may include Retry-After. The status by itself is not about click fraud. It is about request frequency to a server, not about interest in an ad.

You need this if your logs are filling with 429, or if 429 is absent while the sign-in form is buried in attempts. Below: what the specification does not promise, and why frequency alone is not enough to block a person.

The status does not say whom you counted

The specification does not define how the server identifies the user or how it counts requests: per resource, per server, or across a group of servers; by credentials or by cookie. Two products can both answer 429 and mean different things. One counts an IP, another a session, a third a login. The client sees the same status.

The phrase “50 requests an hour” in the document is an example of a response body, not a norm. Do not take your threshold from that example.

The security considerations say that under attack, or under a very large flow, a 429 response itself spends resources. The server is not required to send it and may simply drop connections. A log with no 429 does not prove there is no limit. The connection may have been cut before a response.

A captcha, an IP block, and a computational task are not the same trick

The OWASP section on credential-stuffing defense is about sign-in. A captcha on a sign-in attempt helps notice automation and can slow guessing, but it is not perfect: tools and services solve captchas with a noticeably high success rate. Program names and bypass steps are not part of this description.

An IP block stops simple guessing and should not be the only defense. An address is easy to change. A distributed approach through proxies keeps the frequency from one address low — low enough that a per-IP limit stays quiet while the account receives many attempts.

Client-side checks, including JavaScript, can be forged, so OWASP requires a second layer. A computational task in the same section is cryptographic or proof-of-work: the client is given work so the attack takes longer. No person is required in the loop. The trick limits the rate of one particular client implementation. Refusing visits that have no JavaScript hurts accessibility, including screen readers. This is a description of sign-in defense, not the parameters of Binetro’s task.

Adam Back’s paper of 1 August 2002 describes hashcash as a way to slow systematic abuse of unmetered resources, originally mail and anonymous remailers. The author dates the first proposal to May 1997. A cost function mints a token that is proof of work. It should be cheap to verify and configurably expensive to compute. In the interactive variant the server issues a challenge to the client. The paper separates this from a captcha: there is no person in the loop, and the price is the amount of computation. The minting formula and the number of zero bits are not part of this description. The paper does not set a difficulty for a web visit.

Frequency alone is not enough to block

Binetro treats a wrong decision against a live person as worse than a missed bot. One weak signal, including request frequency alone, is not enough to block a visitor. How weak a signal must be is not part of this rule. The practical conclusion is already there: a 429 or a burst of requests is recorded and read together with other signals. The burst by itself is not a ban.

Read one 429 as a card, not as a verdict. A Retry-After value, if present, says when the client is invited to try again. It does not say whether you counted an IP, a cookie, or a login. Two identical statuses in one hour can refer to different resources: the count may be per resource, per server, or across a group of servers, by credentials or by cookie. A chart of “how many 429s today,” with no label of what was counted, cannot be compared across products.

Keep the captcha limit and the address limit beside it. A captcha on sign-in slows automation and does not close it: the test is solved at a noticeably high success rate. An address you blocked is easy to change. Through proxies the rate from one address stays low, and a per-IP limit stays quiet while the account receives attempts. JavaScript in the browser can be forged, so a second layer is required. A computational task stretches the attack with no person in the loop and limits one client implementation. Refusing visits with no JavaScript hurts accessibility, including screen readers. Hashcash has the same role: the token is cheap to verify and configurably expensive to mint, the price is the amount of computation, and there is no person in the loop. That is not a Binetro threshold. The phrase “50 requests an hour” in the RFC is an example response body, not a norm.

For sign-in, keep three columns and do not collapse them into one number. The first is how many 429s reached a client, and whether connections were dropped with no status: under a very large flow the server may refuse to spend resources on a response. The second is whether a second layer exists besides an IP and besides a script in the browser. The third is whether you block a person on frequency alone. Binetro closes the third column with a rule: frequency alone is not enough. An advertising click does not belong in these columns.

The manual limit: you can set a threshold on a login or an address and see 429. You will not see a distributed approach that stays under the threshold from every address. The second layer is the one OWASP requires beside a client-side check: not only JavaScript in the browser and not only an IP list. Binetro does not block on frequency alone. It does not refund a click: the ad platform charges it. Who clicks ads, how click fraud differs from sklikivanie, when an invalid click is not refunded, and whether the budget comes back are questions for the ad account, not for status 429.