The contact form is flooded with spam submissions, should you add honey trap fields first or implement captcha verification first.

When the contact form is flooded with spam submissions, should you add a hidden honey pot field first or apply captcha? Add the honey pot field first. It does not disturb real visitors in any visible way, can block a part of script submissions that do not render; place the captcha in the second step, only when the remaining spam volume still affects business, because the captcha will also block a part of real users.

First judge what type of spam it is

Before starting, check the submission records. The garbage is roughly divided into three categories, with different handling methods.

The first category is script batch submission. The characteristics are short submission intervals, mechanical field filling, repeated appearance of the same source address, and a lot of blank or placeholder content. This is the source of quantity, and it is also the main target of honey pots and frequency limits.

The second category is semi-automatic submission. It will fill in reasonable content, but the same sentence will appear with different punctuation, often bypassing simple repetition detection. This type needs to rely on content-level filtering.

The third category is manual or proxy submission. The quantity is less, and the content is natural, making it difficult to resist any front-end means, and it can only be verified by background review and contact method verification.

In terms of statistics, robots have already accounted for 45% of the global internet traffic, and the automatic submission of unprotected sites accounts for more than half, so the first category usually constitutes the main body of the quantity, and solving it can achieve the fastest effect.

What can the honey pot field resist?

The method of honey pot is to place a real user invisible and unfillable input box in the form. The stylesheet hides it, so people won't fill it, and most scripts that directly traverse by field name will fill it in; the server will judge it as machine submission if it sees that the field is not empty, and directly discard or enter the pending review queue.

Its boundary also comes from the same principle: if the script renders the page first, parses the style, and then decides which fields to fill, it can skip this box. The relevant test data shows that the honey pot has an interception rate of about 40% for basic script submissions. Therefore, the honey pot is suitable as the first layer to eliminate the easiest part to block, but it is not suitable as the only solution.

There are three details to pay attention to when configuring. The field name should be natural, avoiding being easily recognized as a detection item; do not make the honey pot a required check, otherwise, the real user leaving it blank will cause an error; after the server determines it, leave a record for convenient subsequent statistics of how many were intercepted.

When should the captcha be used?

After honey pots and frequency limits, if spam still accounts for a considerable proportion of the submitted volume, consider captcha. There are three signals to judge whether to use it: natural content appears in the spam, the types passed by the honey pot; the same source was restricted and continued to submit after changing the address; the volume of manual review has already affected the response time.

The cost of captcha should be considered together. While it blocks machines, it also blocks a portion of real visitors, especially those with mobile and network environment restrictions; there are also large-scale proxy services, which means spending money to have real people help machines complete the verification, meaning it blocks low-cost submissions, not all automation.

In AnQiCMS, forms can be connected to reCAPTCHA for robot verification, which belongs to the second level of configuration. Whether to enable it, and on which forms to enable it, it is recommended to decide according to the previous three signals, rather than enabling it on the entire site by default.

The order and exceptions of the two layers

The regular order is four steps: first put up the honey trap field, then do source and frequency restrictions, then decide the captcha according to the remaining spam volume, and finally use content filtering to catch the leaked text spam.

Content filtering is often skipped. Features such as contact information, external links, and repetitive sentences are handled by sensitive word filtering and keyword replacement rules, which can block submissions that have passed several layers but are actually advertisements or phishing. AnQiCMS's content review process can keep suspicious submissions in a pending confirmation status instead of directly storing them in the database.

There are two exceptions. Open registration sites or forms collecting information publicly have a lower cost of manual review than the cost of mistakenly blocking real users, so captcha can be directly applied and honey pots can be retained; conversely, for internal contact or after-sales forms, it is better to have a few more pieces of spam than to disturb the user, and only honey pots and frequency limits should be left.

No matter which one, after the change, you should observe the submission volume and blocking records for one to two weeks, to confirm that the blocking has increased while the real submission has not decreased.

Common questions

Is it enough to just add honey pots?Useful for spam mainly submitted in batches using scripts, and it does not disturb. If natural content and address changes appear in the spam, frequency limits and captcha should be added.

Why is there still spam even after adding captcha?There are services for manual verification, which can be paid for per verification to complete the verification, so the captcha blocks low-cost automation, but not all submissions. Content filtering and backend review are still needed.

Should the submissions that are blocked be recorded?Yes, they should be recorded. Without a record, it is impossible to judge the blocking rate, and it is also easy to trace back when real users are mistakenly blocked. The record should keep the source, time, and the reason for the determination.