Configure Web Bot Detection

Reading time: About 12 minutes
Prerequisites: The hostname has been onboarded, and the Bot Management master switch is enabled.

Feature Overview

Web Bot Detection is a frictionless human-verification capability built for web page scenarios, designed to strengthen the identification of and defense against Bot traffic in browser environments. It applies to Web/H5 pages, including pages loaded through the built-in browser inside an app or mini program.

This feature works by injecting a lightweight JavaScript SDK (a few dozen KB) into the page to precisely collect browser-environment and interaction signals, which are then combined with server-side policies for a comprehensive risk assessment.

Key risk scenarios addressed:

• Automated access using a spoofed or non-genuine browser environment.
• Malicious crawlers or credential-stuffing attacks driven by automation frameworks controlling a browser.
• Bulk automated operations that lack genuine user interaction (such as no mouse movement or keystrokes).
• Malicious debugging, tampering, or bypass attempts targeting the frontend security detection logic.

Note: Once this feature is enabled, the cloud security platform automatically injects the JS SDK into the HTML pages returned by your site. Because this changes how page content is returned, it may conflict with certain frontend scripts, page compatibility settings, or browser environments. We recommend validating the feature in a test or staging environment before enabling it in production.

How It Works

Web Bot Detection uses a closed-loop mechanism of "client-side page injection + environment/behavior collection + state correlation + cloud-based comprehensive decision-making."

• Frictionless injection: When a real user visits the page, the cloud security platform automatically injects the security JS SDK into the response body.
• Signal collection: While running in the browser, the JS SDK only collects information used to determine whether the current visit is more consistent with real-user browser behavior; it does not collect the actual content entered by the user.
  • Basic browser information: browser language, screen resolution, time zone, and so on.
  • Environment risk information: detects whether the browser is running automation tools such as WebDriver.
  • User interaction events: keyboard, mouse, and touchscreen events.
• State correlation: The platform plants a specific cookie or appends a URL token to asynchronous requests, binding the signals collected on the frontend to subsequent business requests.
• Comprehensive assessment: The cloud-side backend evaluates risk based on multiple signal dimensions and takes action — such as Log or Deny — according to your policy configuration.

Configuration Steps

1. Log in to the console and go to the subscribed security product page.
2. Go to Protection Settings > Policies.
3. Locate the hostname you want to configure, click , and go to the Policies editing page.
4. Select the Bot Management tab. If Bot Management is off, turn it on first.
5. Under Web Bot Detection, enable the relevant detection capabilities and configure exception scenarios.
6. After confirming the configuration, click Deploy at the bottom to push the configuration (takes 1–3 minutes to take effect).

Objects Added by the Platform

Once this feature is enabled, the platform adds the following objects to your pages and requests. Please confirm these do not conflict with your business:

• JS SDK embedded by the cloud security platform during the response phase:

  JS SDK	Cache Duration
  /_fec_sbu/hxk_fec_[version].js	30 days

• Cookies added by the cloud security platform during the request phase:

  Cookie Name	Duration	Applicable Protocol	Secure	HttpOnly
  FECW	10 years	HTTPS	√	×
  FECA	Session	HTTPS	√	×
  FECN	10 years	HTTP	×	×
  FECG	Session	HTTP	×	×

• In addition, the cloud security platform adds the following URL token to asynchronous API requests on this site:

  Token Name	Example
  FECU	http://www.example.com/test.html?id=1&FECU=[value]

Note: After enabling Web Bot Detection, page content, cookies, and some asynchronous request URLs may change. We recommend validating the following before enabling it in production:

• Page script compatibility
• Whether frontend resources load correctly
• Whether asynchronous API requests allow additional URL parameters
• Whether strict validation logic exists for cookies or URL parameters
• Whether this conflicts with CSP, caching policies, or other security configurations

Configuration Items

Web Bot Detection includes the following 5 capability dimensions. Browser Feature Validation is the baseline capability and cannot be disabled on its own; the remaining capabilities can be enabled or disabled based on your business needs.

Exception Scenarios

In certain business scenarios, you need to configure exceptions to keep your business running normally:

Scenario 1: HTML pages that should not have JavaScript embedded (JS Injection Exceptions)

If a specific HTML page has JavaScript-injection compatibility issues, you can add a URI exception for it.

Scenario 2: Ajax request exceptions

The JavaScript file delivered to the client by Web Bot Detection performs ongoing verification by dynamically appending a URI token to Ajax requests. Because Ajax requests are not cached by default, this can cause the request to be answered repeatedly, increasing bandwidth usage — so the system excludes these requests from verification by default.

• This is a trade-off between security and cost: if you want stronger access security for these requests, you can remove the Ajax request exception.
• However, if your website enforces strict validation on URL parameters, we do not recommend removing the Ajax request exception.

Scenario 3: Non-HTML application request exceptions (Bypass Traffic from Specific Clients)

If your website receives requests from any of the following clients, you need to configure an exception under Custom Request Exceptions based on the request characteristics before using Web Bot Detection, to prevent these requests from being mishandled by Web Bot Detection and disrupting normal business operation.

• Native apps
• Native mini programs
• API calls from third-party applications

Custom Request Exceptions:

• Name: Enter a name for the exception rule.
• Rule Description (optional): Enter a description of the rule.
• Match Conditions: Enter match conditions based on your application’s needs. You can configure multiple match conditions, which are combined with AND logic. A single match condition can contain multiple values separated by a delimiter, which are combined with OR logic.

Best Practices

To ensure a smooth business transition while maximizing security effectiveness, we recommend the following three-step approach:

• Check frontend environment compatibility (before launch)
  If your site uses CSP, frontend integrity checks, resource caching controls, or special page-rendering logic, confirm compatibility with the JS injection mechanism before enabling this feature.
• Roll out gradually, then scale up (early deployment)
  For sensitive pages such as payment, transactions, or login, we recommend enabling this feature for a small pilot group first, confirming there is no impact on the normal user experience, before gradually expanding coverage.
• Precisely protect high-risk assets (policy refinement)
  • Prioritize covering core business flows with Web Bot Detection: registration, login, password recovery, SMS sending, placing orders, flash sales, and other scenarios commonly exploited by black-and-grey market automation at scale.