The protection rules engine defends your website against common web attacks, including SQL injection, cross-site scripting (XSS), remote code execution, and webshell attacks. This page explains how to configure the engine for your traffic, interpret protection results, and respond when legitimate requests are blocked.
The protection rules engine does not cover server intrusions caused by host security issues, such as unauthorized access to ApsaraDB for Redis or ApsaraDB RDS for MySQL.
How it works
After you add a website to WAF, the protection rules engine is enabled by default and applies the Medium rule group. Incoming requests are evaluated against the active rule group. Depending on the mode you select:
Block — WAF blocks matching requests and logs the attack.
Warn — WAF logs the attack but lets the request through.
Configure the protection rules engine
Go to the Website Protection page to view and update Protection Rules Engine settings. For step-by-step instructions, see Configure the protection rules engine.
Step 1: Choose a rule group
Select the rule group that matches your traffic and tolerance for false positives.
| Rule group | Description | Trade-off |
|---|---|---|
| Loose rule group | Blocks common web application attacks | Lower detection coverage; lower false-positive rate |
| Medium rule group (default) | Blocks common web application attacks in a standard way (attacks can bypass protection policies) | Balanced detection for common web attacks |
| Strict rule group | Blocks web application attacks in a strict way (attacks can bypass complex protection policies) | More aggressive matching; higher risk of false positives |
Start with the default Medium rule group. Switch to Strict only after validating that normal traffic is unaffected in Warn mode (see Step 2), because the Strict rule group's broader matching patterns are more likely to flag legitimate requests.
If you use WAF Business or Enterprise in the Chinese mainland, or WAF Enterprise outside the Chinese mainland, you can also customize protection rule groups to combine rules for your specific requirements.
Step 2: Validate in Warn mode before blocking
Set Mode to Warn before enabling blocking. In this mode, WAF logs potential attacks without affecting traffic, so you can identify false positives before they impact users. Running in Warn mode for one to two weeks gives your traffic enough diversity — including edge-case requests — to surface patterns that would be blocked.
After one to two weeks, review the attack logs on the Web Intrusion Prevention tab:
If no normal traffic appears in the logs, set Mode to Block.
If normal traffic is being flagged, handle false positives before switching to Block (see Handle false positives).
If you add phpMyAdmin and development technology forums to WAF for protection, WAF may block normal traffic. If this occurs, we recommend that you contact Alibaba Cloud security experts to resolve the issue.
Step 3: Avoid triggering detection rules in your application
Certain application behaviors increase the risk of false positives regardless of rule group. Avoid the following patterns in normal business traffic:
Passing raw SQL statements or JavaScript code in HTTP request parameters.
Using SQL keywords such as
UPDATEorSETin URL paths — for example,www.example.com/abc/update/mod.php?set=1.Uploading files larger than 50 MB through the browser. Use Object Storage Service (OSS) instead.
View protection results
After enabling the protection rules engine, view its results in Security report > Web Security > Web Intrusion Prevention tab.
The tab shows attack records from the last 30 days, with charts and a detailed record list. To inspect a specific event:
Select Regular Protection in the filter.
Find the attack record and click View Details.
The following figure shows an example of an SQL injection request that WAF blocked.
Handle false positives
If WAF blocks legitimate traffic, we recommend that you configure a whitelist for the blocked URLs in the Web Intrusion Prevention section and then contact Alibaba Cloud security experts to find a solution.
Identify the blocked URL. Find the specific request in the attack logs on the Web Intrusion Prevention tab, and note which URL is being blocked.
Configure a whitelist for the affected URL. Add the URL to the whitelist in the Web Intrusion Prevention section. This exempts those requests from engine inspection without disabling protection for the rest of your website. For instructions, see Configure a whitelist for web intrusion prevention.
Contact Alibaba Cloud security experts. If the whitelist does not fully resolve the issue, or if the scope of false positives is broad, contact Alibaba Cloud security experts for analysis and a tailored solution.
Stay current with rule updates
WAF updates protection rules and publishes protection bulletins to address known and zero-day vulnerabilities. To check the latest updates, go to the Product Information page. For instructions, see View service information.
Web attacks have more than one proof of concept (POC). Alibaba Cloud security experts conduct a thorough analysis of vulnerability principles to ensure that published protection rules cover all disclosed and undisclosed vulnerabilities.