Defend against common CC attack scenarios using Alibaba Cloud Web Application Firewall (WAF) with targeted protection policies and configurations.
Overview
Select the scenario that best matches your needs:
High-volume, high-frequency CC attacks
In large-scale CC attacks, bots send requests far faster than normal users. Rate-limit the request source directly. Use the Rate Limiting of a Custom Protection Policy in WAF to configure a rate-limiting policy. Configure a custom protection policy.
Example: Block an IP address for 10 hours if it accesses any path on the domain more than 1,000 times in 30 seconds. This rule works well as a general measure for small and medium-sized websites.
Adjust the protection path, trigger thresholds, and action based on your business requirements. For example, to protect a login interface from credential stuffing, specify the login URL (use the Prefix Match logic and set Matched Content to/login.php), then block any IP that exceeds 20 requests within 60 seconds.
Notes on CC protection:
-
The Slider CAPTCHA and Run Strict Slider CAPTCHA options for the Action verify whether requests come from real browsers rather than automated tools. These options apply only to webpages and H5 pages, not native apps or APIs. For apps or APIs, set the Action to Block.
-
To prevent false blocks on specific interfaces or IP addresses, whitelist them using the Access Control/Throttling feature. Set an access control/rate limiting whitelist.
-
Do not enable the Emergency mode of HTTP Flood Protection for apps or APIs.
If you have a WAF Enterprise Edition instance, you can use custom statistical object fields beyond IP and Session for more granular rate limiting. For example, IP-based blocking may affect users behind a NAT gateway. Instead, use a cookie or user-level parameter as the statistical object. The following figure counts requests by a user-identifying cookie (for example, a cookie in the formatuid=12345) and uses the slide action to prevent false positives.
Attacks from overseas or public clouds
CC attack traffic often originates from overseas, public cloud, or IDC IP addresses.
For websites that primarily serve users in China, block access from IP addresses outside the Chinese mainland with the Region Blacklist feature in WAF. Configure an IP blocklist.
With the Bot Management module enabled, use the Bot Threat Intelligence feature to block crawlers from common IDC IP libraries, including Alibaba Cloud, Tencent Cloud, and other data center IP ranges.
Crawlers are commonly deployed on cloud servers. Legitimate users rarely access services from public cloud or IDC IP addresses.
Example: Enable the following rule to block Tencent Cloud crawler IP addresses. Configure a crawler threat intelligence rule.
Malformed or unreasonable requests
CC attack requests are often arbitrarily constructed. Log inspection reveals malformed characteristics that distinguish them from legitimate traffic:
-
Abnormal or malformed User-Agent: The User-Agent contains automation tool signatures (for example, Python), is malformed (for example,
Mozilla///), or is illogical (for example,www.example.com). Block these requests directly. -
Unreasonable User-Agent: For an H5 page promoted on WeChat, legitimate users access it through the WeChat app. A Windows desktop User-Agent (for example, MSIE 6.0) indicates an unreasonable request that you can block.
-
Abnormal Referer: Block requests with no Referer or a fixed Referer from an illegitimate site. This does not apply to homepage or first-visit access. For URLs accessed only via internal navigation, analyze the Referer for anomalies and block suspicious requests.
-
Abnormal cookie: Legitimate users include service-related cookies in requests (except on first visit). Many CC attack requests lack cookies entirely — block them.
-
Missing HTTP headers: Legitimate requests include required service headers (for example, authentication headers) that attack requests lack.
-
Incorrect request method: If an interface accepts only POST requests but receives a flood of GET requests, block the GET requests.
Create blocking policies for these characteristics using ACL rules in a Custom Protection Policy. Configure a custom protection policy.
Configuration examples:
-
Block requests that do not include a cookie.

-
Block requests that do not include an authorization header.

Interface abuse
For critical web interfaces (including H5) such as login, registration, voting, and SMS verification, use the Data Risk Control feature.
Data Risk Control inserts JavaScript into critical interface pages to collect user behavior and environment data. It determines whether requests originate from real users or automated scripts through human-machine verification, independent of request frequency or source IP. This makes it effective against low-frequency, distributed attacks.
Data Risk Control relies on verification parameters included in normal requests after protection is enabled. This feature does not work in environments that cannot execute JavaScript, such as APIs and native apps. To avoid false positives, test in a staging environment first, or enable observation mode and consult YUNDUN engineers before switching to protection mode.
Malicious scanning
Large-scale scanning strains servers. In addition to rate limiting, use the Scan Protection feature for enhanced protection:
-
High-frequency Web Attack Blocking: Automatically blocks client IP addresses that repeatedly trigger web protection rules.
-
Directory Traversal Prevention: Automatically blocks client IP addresses that perform multiple directory traversal attacks within a short period.
-
Scanner Blocking: Automatically blocks access requests from common scanning tools or IP addresses in the Alibaba Cloud malicious scan attack IP library.
-
Collaborative Protection: Automatically blocks access requests from IP addresses in the Alibaba Cloud global malicious scan attack IP library.

App attacks
Beyond frequency settings, region-level IP blocklists, and ACL-based access control, you can integrate the YUNDUN SDK for app protection.
The SDK signs and validates app requests using hardware signals to verify they originate from your official app. Unverified requests are blocked. This allowlist approach permits only legitimate requests without analyzing malicious traffic characteristics.
To use SDK-based protection, enable the App Protection module. Configure App Protection.
Malicious crawling
For content-rich websites (credit reporting, real estate, airfare, novels), crawlers can cause bandwidth spikes, high server load, and data breaches. If other methods are insufficient, use the Bot Management module for targeted protection. Configure a Bot Management whitelist.