How to protect a form from bots without a captcha
Contents
Share
A form can be met without a visible captcha: a hidden empty field, email confirmation before the account is live, and a submission check that shows no puzzle. One such trick is fragile. The form itself does not undo click fraud: a click and a lead are different events.
Below is an order built from the OWASP description, the Cloudflare Turnstile scenario, and how Binetro uses a computational task. Rate thresholds and field markup are not part of this order.
Name the point before you pick a trick
OWASP does not set the job as “stop every bot.” Search crawlers, monitoring, and accessibility tools are legitimate. The job is to raise the cost of malicious automation without hitting people and legitimate bots.
Protection is assembled from three layers: the network edge, the application, and business rules. Before you pick a trick, sort events by point. Sign-in, registration, the catalog, and checkout are built differently. A “leave your phone” form is not the sign-in form and not the cart.
If you put one trick on every address of the site, you mix legitimate page crawling with lead submission. The lead needs its own set. The catalog needs its own.
What to put on the form itself
A hidden field marked “leave this empty” is an application-layer trick. OWASP describes it as something bots fill in and a person does not. A non-empty value is a reason to reject the submission. The trick is cheap and does not affect an ordinary visitor.
OWASP does not publish a catch rate, so the field is not a measured share of spam. It is a signal on one submission.
Do not make a visible captcha the main defense here. It is poor for accessibility, machine learning solves it, and human solving services take it. Its place is a fallback when the check needs to step up. Proof-of-work raises the cost of an automated request and does not prove the client is a person. A task that is too hard can refuse a live visitor.
Separately, the Cloudflare Turnstile widget on Free, Pro, and Business plans, in that scenario, checks suspicious bots before a sign-in, registration, contact, or checkout form is submitted, and it does not show the visitor a captcha. The widget can be embedded on the site without sending all traffic through Cloudflare. That is a description of a Cloudflare product, not a general law of forms and not Binetro’s behavior. The widget does not subtract clicks in Yandex Direct or Google Ads.
Rate limiting in the same scenario is a different trick. Together they cover different cases: Turnstile meets automated submission on the form, and rate limiting meets volume that never passes through the form, including a direct POST that bypasses the widget. Thresholds and rule expressions from that scenario are not part of this order.
Do not turn the first weak signal into a refusal
OWASP treats a hard refusal on the first signal as a mistake. So is refusing everyone whose browser is hardened for privacy: those visitors often look like a bot. The preference is a check, not a refusal.
Split the response by confidence:
a weak suspicion — record it and still serve the visitor;
medium confidence — an extra check;
confirmed abuse — a manual review.
Tricks that corrupt the response or deliberately slow it are not part of this order. These are not Binetro’s thresholds.
For a suspicious visit, Binetro may issue a computational task in the browser. A correct solution confirms the check and can change “challenge” to “allow.” It does not undo a “block” decision. The task cannot be offered instead of an allow. Difficulty, lifetime, and format are not published. This is not a captcha on the form and not a replacement for the hidden field: the field looks at the submission, the task looks at the visit, and a blocked visit stays blocked.
Email and phone before the account is live
For account creation, OWASP separates two messages. The email has to be confirmed before the account becomes usable. A “you are registered” message is not enough.
For a phone number, look at the carrier line type. VoIP numbers are numerous and cheap — that remark has no year and no sample, so it is not a share of your leads. Disposable email domains are checked against a list. A threshold of “how many registrations from one address” is not set here. This is also not Yandex Direct’s rule about a wrong phone number: a bad advertising contact and an unconfirmed account are different decisions.
Order for a lead form
Separate the lead form from sign-in, registration, the catalog, and checkout. Do not copy tricks from one point to another.
Add a hidden empty field and reject a non-empty submission. Do not expect a share of “all bots” from it.
Confirm email before the account is live. Check disposable domains against a list. For a phone, look at line type, not only at the digits arriving.
Record a first weak signal and still serve the visitor. Turn on an extra check at medium confidence. Review confirmed abuse by hand.
If you want a widget without a captcha, Turnstile in the scenario above meets form submission. Beside it, separately, rate limiting meets a direct POST past the widget.
Keep a visible captcha as a fallback. Do not treat a computational task as proof the client is a person. If the visit is already blocked, Binetro’s task does not undo that block.
The manual limit is this: you see the submission and can reject an obvious trap, but you do not see which client skipped the field and posted past the widget until a second control looks at volume. Binetro on the site looks at the visit and can issue a browser task or block. It does not promise a live person never sees a check, and it does not refund a click: the ad platform charges the click.
Who clicks ads, how click fraud differs from sklikivanie, why invalid clicks are not always refunded, and whether the platform returns the money are decided under the platform’s rules, not by whether a hidden field passed.