Configure Workflow Detection

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

What Is Workflow Detection

Workflow Detection is a proactive defense feature built around business logic. Its core principle is that normal users inevitably follow a certain behavioral pattern. By analyzing the number of requests a client makes within a given time window and the distribution characteristics of the resources it requests (for example, whether it accesses a single API in isolation, or whether the ratio of static-to-dynamic resource requests is abnormal), the system precisely identifies and blocks abnormal Bot behavior that bypasses the frontend page and calls core APIs directly through a script.

Workflow Detection addresses the following problem: to reduce cost and avoid detection, advanced Bots often use low-frequency, distributed attack techniques, which causes traditional rate limiting to become ineffective. Normal user behavior, however, follows a logically coherent sequence that Bots typically cannot fully replicate.

Typical Scenarios

Web scenario: Static/dynamic resource access pattern validation

Normal user behavior: When a real user visits a web page through a browser, the browser automatically loads a large number of static resources (.js, .css, images, and so on) along with a small number of dynamic API calls. As a result, the types of resources requested are broadly distributed, and the ratio of GET/POST requests falls within a reasonable range.

Bot behavior: Bots typically do not need to render the full page — they usually request only the dynamic APIs, so the proportion of static resource requests is extremely low, and in some cases every request is a POST request.

Detection mechanism: The system tracks the total request volume, GET/POST request volume, and the proportion of requests for different resource types within a statistical period. If a client’s proportion of dynamic requests is abnormally high, or its GET/POST ratio is severely skewed, the system flags it as a Bot and blocks it.

API scenario: Related-endpoint call validation

Normal user behavior: When a real user performs a business action (such as booking a ticket), it triggers a series of related API calls. Over a given period, this includes both calls to the query API and calls to the order-placement API.

Bot behavior: To maximize efficiency, Bots typically run a hardcoded script that calls the core order-placement API in isolation, without going through the related calls.

Detection mechanism: The system analyzes the total number of requests a client makes within a statistical period, or the number of requests to other related URLs. If a client repeatedly calls the “place order” API at a high frequency but has made zero calls to the “query” API, the system flags this as an isolated, illegitimate call and blocks it.

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 Edit, and go to the Policies editing page.
4. Click the Bot Management tab at the top. If Bot Management is off, turn it on first.
5. Configure detection rules under Workflow Detection.
6. After configuring the rule, click Deploy at the bottom to deploy the configuration (takes 1–3 minutes to take effect).

Rule Configuration

Configuration Example: Preventing Ticket/Order Scalping

Business background: A site administrator wants to protect the core ticket-booking API /booking.do, which is targeted by black-and-grey market operators and is frequently called in bulk directly by scripts.

Defense design: A genuine visitor always calls the preceding CAPTCHA-retrieval API /get_verification before calling /booking.do. If, within a 300-second window, an IP calls the booking API directly without ever having called the CAPTCHA API, the system treats this as an illegitimate script and blocks it.

Rule configuration:

• Rule Name: Booking scenario – block isolated core-API access
• Protection Target: Path exact match /booking.do
• Use Case: API scenario
• Trigger Condition: Within [300] seconds, based on [Client IP], the access behavior [meets all] of the following conditions:
  • Custom URL request count exactly matching /get_verification is less than 1
  • Custom URL request count exactly matching /booking.do is greater than or equal to 1
• Action: Locate the rule created above and set its action to Deny.

Effect: If a visitor calls the booking API directly without ever having requested the CAPTCHA API, the system identifies this as an abnormal script and blocks it.

Recommendation: When configuring this rule for the first time, set the action to Log first. Once you’ve confirmed the rule behaves as expected, switch it to Deny — this avoids mistakenly blocking normal users.