The form is flooded by robots, where should the captcha be added?

Form is flooded by bots, the captcha should be added at the submission layer of the public entry, not just on the login page. The criteria are simple: any form that can be submitted directly from the outside and whose submission results in data going into the background or onto the page needs to be checked separately for protection, including messages, contact us, registration, comments, and the in-site search box. The captcha solves the problem of 'whether it is a real person,' it cannot stop real people from submitting garbage, so the filtering of sensitive words, keyword replacement, and content review after submission need to be followed up, which is the complete two-line defense.

From which entries does the flooding come in

A large number of duplicate messages appear on the back end, usually not from the same entry. The four common types are: message and contact us forms, registration and password recovery forms, comment forms, and search pages that echo search parameters verbatim. The first two types write data directly, while the latter two may be used to test page injection. Attack scripts generally send requests directly to the submission address without page rendering, so doing validation only in front-end JavaScript is equivalent to not doing it at all - placing the validation at the rendering layer, the script can bypass it.

Where should the captcha be added?

The correct layer is「before the submission action occurs, and the server will verify this verification result」. AnQiCMS's forms can integrate reCAPTCHA verification codes, and forms such as comments require real-person verification at the submission stage, and the server will only write data after confirming that the verification is passed. There are three criteria to determine which layer it falls into:

The first is that the position should be close to the submit button, not just blocking the login page. Water filling occurs on the message page, but the captcha only appears on the backend login page, which is equivalent to not managing it. The second is that the verification should be completed on the server side. The front-end only checks if it is filled in, and scripts can still submit. The third is not to block the real person path. The captcha should only appear at the step where it is needed to prove that it is a real person, browsing the page, flipping pages, and reading articles should not require answering questions, otherwise, normal users will be driven away.

The second line of defense after submission

Rubbish submitted by real people, as well as garbage that bypasses validation, needs to be handled by content security settings. Sensitive word filtering takes effect at the writing stage, and submissions that hit the rules will be blocked or marked; keyword replacement is used to batch change existing expressions, suitable for handling historical content after changes in the rules口径. Content review is then done once again before the content appears on the page, manually or by rules, to close the edge cases that machines cannot judge. These three items work together to significantly reduce the amount of manual cleaning of comments.

There is an easily overlooked layer of protection on the page side: anti-interference code for collection. Websites that are collected in bulk often attract secondary flooding because junk sites can directly reuse your content structure. The built-in JWT authentication and defense against SQL injection and XSS handle cases where the submitted parameters themselves are constructed for attacks, and belong to the parts that need to be opened together in the same set of security settings.

Four situations to be verified before going online

First, is the POST submission address rejected without verification? Second, is it better to give a clear failure instead of silent writing when the verification answer is deliberately filled in incorrectly? Third, when the content submitted hits the filtering rules, does the background have a traceable status instead of disappearing directly? Fourth, can normal messages that are mistakenly blocked be restored - deleting formal documents is moved to the recycle bin instead of being physically deleted, and there is still a chance to recover mistakenly cleared content.

Common questions

Is it better to have more layers of captcha?No. Each time a real person answers a question on the path, there is a loss, and the focus should be on server-side verification and content review after submission.

Is the message already in the background and still spam?It is. It went into the background but didn't go to the page, the problem is in the cleaning cost; it only affects the reader and search experience when it goes to the page, so we need to prioritize the processing.

Is it okay to rely only on IP limiting?Not enough. IPs will rotate, scripts will be submitted in a distributed manner, and traffic limiting can only slow down the speed, but cannot judge whether the submitted content is spam.