What a honeypot field in a form actually does

A honeypot field is a hidden form field marked “leave this empty.” OWASP describes it as something bots fill in and people do not. If the field arrives with a value, the submission is rejected. The check is cheap and does not change the form for an ordinary visitor. It is one check on a submission, not an answer to click fraud.

You need this if a form on your site takes leads and you want to know what the empty trap actually does before you treat it as protection. Below: the two honeypots in that OWASP section, why a single trick breaks, and where a visible captcha sits.

What rejects the submission

A person sees the usual fields: name, phone, comment. The hidden field is in the markup, not in the interface, and the note says not to fill it. An automated client that walks every field and puts a value in each one often fills this one too. The server looks at the value that arrived. An empty field lets the submission continue. A non-empty field is a reason to reject that submission.

OWASP calls the trick cheap: the visitor is not shown a puzzle and is not asked for an extra action. For a person who never sees the field, the form stays the same.

OWASP does not publish a catch rate or a false-reject rate for this field. “Cheap and invisible” does not mean the field stops automated leads. If you drop spam with this check alone, you do not know how many automated submissions walk past it.

Why one field is not enough

The job OWASP sets is not “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.

A single trick is fragile. Protection is assembled from three layers:

• the network edge, which meets the request before the application;

• the application itself, including the form and its field checks;

• business rules: what counts as an acceptable lead, registration, or order.

The hidden field lives in the second layer. It does not replace the edge, and it does not replace a rule such as “a lead with an unconfirmed contact does not go to the sales queue.”

Before you pick a trick, OWASP asks you to see which automated-threat events belong to which points in the app. Sign-in, registration, the catalog, and checkout are built differently. A field that rejects an empty “call me” submission does not answer who is browsing the catalog or who is pressing the order button. Those points are not one rule called “all bots.” A legitimate crawler and a form client are different clients.

Library names, rate thresholds, and the exact markup of the field are not part of this description. The principle is enough: a non-empty hidden field is a signal to reject this submission, not a description of the whole site defense.

The second honeypot: a path a polite robot does not request

The same section describes another trick. A lure path is disallowed in robots.txt. A request for that path is treated as a sign that the client does not follow the directive. Clients that read the protocol are treated as ones that will not request the closed path.

That is not the form field. The field looks at the body of a submission. The path looks at which address the client asked for. Both are called honeypots because both offer an automated client something a person, or a polite robot, does not do.

robots.txt rules are not an access-control grant. A disallow line does not lock the file on the server. A request for the lure is a signal in the OWASP description, not a lock. If the path still returns content, closing it in robots.txt does not by itself remove access.

How to hide the path, and how to walk around it, is outside this description. OWASP does not publish a false-positive rate for the path either. Same limit as the field: a signal is not a measured share of bots.

A captcha here is a fallback, not a replacement

Visible captchas are poor for accessibility. Machine learning solves them, and solving services staffed by people take them. Their place is a fallback when you need to step up the check, not the main defense of the form.

Proof-of-work can raise the cost of an automated request. It does not prove the client is a person. A task that is too hard can itself refuse a live visitor: the person waits, and the server treats the check as failed.

The field and the captcha have different jobs. The field is cheap and invisible to an ordinary visitor. The captcha is visible and hard to access. Neither removes the fragility of a single trick. Replacing the honeypot with a captcha so that “all leads are closed” moves you from a cheap signal to a fallback and leaves you on one layer.

The price of solving a captcha and the names of solving services are not part of this description. What matters is that a visible puzzle does not become the main defense just because someone learned to skip the field.

What to do on your form

The order below uses only these roles. It is not a set of thresholds and not a ready-made configuration.

1. Name the point. Is this a lead form, sign-in, registration, or checkout? Each point has different events.

2. If you add a hidden field, reject the submission when it arrives non-empty, and do not expect a share of “all bots” from that.

3. Do not treat a disallowed robots.txt path as a lock. A request for the lure is a sign the client did not follow the directive.

4. Keep a visible captcha as a fallback. Do not confuse a computational task with proof that the client is a person.

5. Add at least one more layer: the network edge or a business rule for the lead. OWASP treats one field as not enough.

A filled hidden field does not explain who clicks ads, how click fraud differs from sklikivanie, why invalid clicks are not always refunded, or whether Yandex returns the money. Those are separate decisions. The ad platform makes them under its own rules.

If the form feeds advertising goals, rejecting an empty field still does not answer whether the click was live. Look at the submission first. Look at the advertising visit separately.