Workflow Detection

Overview

In combating advanced bots, traditional rate limiting often becomes ineffective, as advanced bots tend to reduce costs and evade detection by employing low-frequency, distributed attack patterns.

Workflow Detection is a proactive defense feature developed based on business logic. Its core principle is that legitimate users inevitably follow certain behavioral patterns. By analyzing the client’s access frequency and resource distribution characteristics within a given time window—for example, whether a specific API is accessed in isolation, or whether the ratio of dynamic to static resource requests is abnormal— the platform can accurately identify and deny abnormal bot activities that bypass the front-end page and directly invoke core APIs via scripts.

Typical Scenarios

Workflow Detection primarily addresses the following two core scenarios:

Scenario 1: Validation of dynamic/static resource access patterns (Web scenarios)

• Normal behavior: When a real user visits a web page via a browser, the browser automatically loads a large number of static resources (.js, .css, images, etc.) along with some dynamic APIs. As a result, the types of accessed resources are widely distributed, and the ratio of GET/POST requests is reasonable.

• Bot behavior: Bots usually do not need to render the full page. They typically request only dynamic APIs, with a very low proportion of static resource requests, and in some cases all requests may even be POST requests.

• Detection mechanism: The system supports detecting metrics such as the total number of requests, GET/POST request counts, and the proportion of different resource requests within the statistical period. If a client’s ratio of dynamic requests is abnormally high, or the GET/POST ratio is severely imbalanced, it will be identified as a Bot and handled accordingly.

Scenario 2: Correlation validation for API calls (API scenarios)

• Normal behavior: When a real user performs business operations (such as booking tickets), a series of related API calls is triggered. Within a period of time, there will typically be requests to both query APIs and order placement APIs.

• Bot behavior: To maximize efficiency, Bots often use hardcoded scripts to directly and independently call critical order placement APIs.

• Detection mechanism: The system analyzes the total number of client requests within the statistical period, or the number of requests to other associated URLs. If a particular client frequently calls the order placement API but makes zero requests to the query API, it is identified as an isolated and unauthorized invocation and will be handled accordingly.

Steps

1. Log in to the console and go to the subscribed security product page.
2. Go to Security Settings–>Policies.
3. Select the domain you wish to configure the security policy and click to enter the Security Policy editing page.
4. Open the Bot Management tab and enable the master switch if it is turned off.
5. Configure detection rules under Workflow Detection.
6. Click Publish Changes at the bottom to publish the configuration. Changes take effect within 1–3 minutes.

Configuration Example

To help you get started quickly, we will use a real case of anti-abuse / anti-ticket-scalping scenario as an example.

1. Business Requirements

The site administrator wants to protect the core ticket booking API /booking.do (this API is frequently targeted by malicious scripts for automated bulk requests).

Security Design: Before accessing /booking.do, a legitimate user must first access the prerequisite verification code retrieval API /get_verification.
If, within 300 seconds, any IP directly calls the booking API without ever calling the verification code API, the request should be treated as an illegal script call and blocked.

2. Console Configuration

Create a new rule under Workflow Detection with the following parameters:

• Rule Name: Booking Scenario - Core API Isolated Access Block
• Protection Target: Path matches /booking.do
• Protected Scenario: API Scenario
• Trigger Conditions:
  Within [300] seconds, based on the [IP] access behavior [simultaneously meet] the following conditions:
  1: Custom URL Request Count exact match /get_verification < 1
  2: Custom URL Request Count exact match /booking.do >= 1

• Action: Save the policy and change action to Deny.

When these two conditions are met at the same time, it indicates behavior consistent with directly bypassing the front-end page and invoking the core API in isolation. The system will then block the request directly.

Note:If you are concerned that directly blocking requests may cause false positives, we recommend selecting Log as the action first. After confirming that the rule is operating as expected, switch to Deny.