When the public interface is brushed, which section does the speed limit, captcha, and exposure range block

When the public interface is brushed, the three levels of means each manage a section: the speed limit blocks the request frequency, the captcha blocks the identity of the requestor, and the exposure range determines whether this path itself is accessible. Not understanding these three sections often leads to the result that a very high speed limit threshold has been set without shutting off the ability that should not be publicly available, or that a captcha has been set but is still frequently called at high frequency, consuming bandwidth

First judge whether the brush is frequency or identity

It can be separated into two categories by looking at the log form. A single source making a large number of requests to the same interface in a short period of time is a frequency issue; not a lot of requests but each tries to complete registration, comments, uploads, etc., is an identity issue; often both appear when a script repeats a legitimate form process.

Where is it more reasonable to implement speed limits?

The location of the speed limit should be close to the exposed layer, such as the reverse proxy or gateway, rather than counting it in the business logic. This way, the consumption will not be transmitted to the database when it is brushed. It is more effective to set thresholds according to the nature of the interface than to cut all at once: document lists, categories, and tags such as read interfaces can be given wider quotas; upload images, leaving messages, and submitting comments and reviews should be more stringent, and counted separately according to the source and access party. The limitations of speed limiting should be clarified in advance: it reduces the damage per unit time, but does not change the reachable surface itself.

What does the reCAPTCHA captcha solve?

The robot submission at the form entry is differentiated by captcha, AnQiCMS supports integrating reCAPTCHA into forms for actions such as leaving messages, registration, and submission, which is used for a human-computer judgment before these actions.It blocks the automated script submission according to the process in bulk, but it cannot block the behavior of passing through manual workshops for verification, so attention should be paid to two things in the configuration: the protected entry points should cover all submission points, and do not just protect the front desk messages while overlooking other forms that will also write to the database;The key binding with the site domain must be checked properly, and the verification will degrade to allow when it is wrong. Outside the form, there is also a layer of content security - sensitive word filtering and keyword replacement take effect before the submission enters formal content, reCAPTCHA solves 'who is submitting', and audit solves 'whether the submitted content can be left', the two layers have different responsibilities.

The scope of exposure is the root.

If a capability does not need to be exposed externally, speed limits and CAPTCHAs are just prolonging its life. The MCP interface sets the exposure range based on the intent domain, operations such as backup, upgrade, and multi-site are turned off by default and need to be explicitly enabled; similarly for public APIs, high-frequency capabilities (document list and details, categories and tags, friend links, system settings and contact information) are suitable for external use, while write and operations actions are not. The specific approach to exposure range is to let the default state bear the security responsibility: keep new sites turned off when launched, open them one by one according to business needs, and clearly write in the documents which capabilities are exposed.

Boundary of public interface document and contact information

It is necessary to publicly disclose the interface document, but the document itself should not become a list of attack surfaces. It is necessary to clarify the calling method, fields, and error return, while avoiding attaching background addresses, real credentials of demonstration accounts, or unpublic management entry paths in the document. Contact information can be disclosed, but it is not necessary to appear in plain text in the main body of the page to be collected in bulk. Identity verification at the interface level is undertaken by JWT authentication, and content protection at the display layer is supplemented by sensitive word filtering and anti-crawling interference code, with each layer performing its duties, so as not to treat 'no one knows this interface' as protection.

Common questions

Ask: Is it necessary to enable captcha for read-only interfaces? Answer: No. The captcha is used for submission actions, while read interfaces are more effective with throttling and exposure range handling.

Ask: After adding reCAPTCHA, the number of comments has decreased. How can you confirm that the protection is working correctly rather than a configuration error? Answer: Compare a real submission with a script submission to see if the verification is actually executed by the server; if the script request is still stored, it means the protection point has not covered this entry.

Ask: How should the speed limit threshold be set? Answer: Set according to the peak shape of normal business, not according to the scale when it is brushed. Allocate tiered read and write interfaces, leave out burst margin, and it is more stable than pursuing a number that looks large.