Security rules-Edge Security Acceleration(ESA)-阿里云帮助中心

Security rules in Edge Security Acceleration (ESA) use a vast threat intelligence library to analyze request attributes, such as the source IP, request path, and User-Agent. The system identifies potentially malicious behavior and automatically issues a challenge to protect your core services.

To configure a uniform security level for all requests to your website, see Set a global security level.

Use cases

Core services such as administration backends, login endpoints, and payment APIs are frequently targeted by automated tools, malicious crawlers, and cyberattacks. A single, fixed global protection policy is often ineffective. If the policy is too strict, it can cause false positives by blocking legitimate users. If it is too lenient, it fails to stop targeted attacks.

By creating fine-grained security rules, you can apply stricter security policies only to requests that access specific paths or have suspicious attributes. This approach provides targeted protection for your core services while minimizing the impact on the user experience.

How it works

The core of ESA security rules is an intelligent decision engine that uses request attribute matching and threat intelligence analysis. When a user request reaches an ESA point of presence (POP), the system sequentially evaluates the request against your configured security rules.

This process involves two core mechanisms: threat evaluation and customizable security levels.

Threat evaluation

ESA's threat detection is powered by Alibaba Cloud's vast threat intelligence library, which aggregates global cyber threat data in real time.

Intelligence sources: Sources include known malicious IPs, attack sources, botnets, and proxy services.
Detection dimensions: The system evaluates multiple aspects of a request, including IP reputation, geographic location, access patterns, and request attributes such as the User-Agent. It then generates a dynamic threat score to help determine the appropriate security level.

Customizable security levels

Security levels define the sensitivity of threat detection and the strictness of countermeasures. Higher levels increase protection strength but may also increase the risk of false positives.

Level	Recommended use case	Description
I'm Under Attack	Recommended only as an emergency measure during large-scale attacks.	Challenges all incoming requests to ensure website availability.
High	For websites currently under attack or during important events that require heightened security.	Challenges any IP address that exhibits suspicious behavior.
Medium	For websites with a history of volumetric attacks or that require enhanced security.	Challenges IP addresses with a higher threat score.
Low (Default)	For routine protection of websites with no clear history of attacks.	Challenges only the IP addresses with the highest threat score.
Essentially Off	Recommended only for temporary use when troubleshooting significant false positive issues.	Retains minimal ESA platform-level protection and challenges only the highest-risk requests.
Off (Available in Enterprise Plans)	Available only in the Enterprise Edition for debugging or special business scenarios.	Completely disables all active security features.

Procedure

After you create rules, ESA evaluates incoming user requests against your rules sequentially based on their rule precedence.

Create a security rule

On the ESA console, navigate to Websites and click the target website in the Website column.
In the left navigation pane, choose Rules > Security Rules.
Click Create Rule and enter a Rule Name.
In the If requests match... section, configure the matching request attributes, and in the Then execute... section, select a security level. For example: For requests with the hostname www.example.com, set the security level to Medium.
Important
Choosing a higher security level increases the risk of false positives. Select a level that balances security with user experience.
(Optional) To change the rule precedence, you can drag the icon in the Order column, or click Move to in the Actions column.

Verify the rule's effect

The security rule takes effect immediately after it is created. When an attacker that meets the rule conditions visits the domain www.example.com, they will receive HTML content that contains a challenge page.

After you pass the challenge, the web page content is returned as expected, and the u_atoken and u_asession information is automatically added to the request URL to identify you as a verified user.

Handle false positives and optimize rules

During rule execution, legitimate user IPs or API clients might trigger false positives. Address these issues promptly. Consider the following scenario:

Your service is under a high-risk attack, and you have set the security level to High. However, you want to allow requests from the internal testing IP address 1.2.3.4.

Method 1: Add a whitelist rule
You can add a WAF whitelist rule to add known IP addresses to a whitelist. This ensures that critical business traffic is not interrupted.
1. On the Security Rules page, copy the corresponding Rule ID.
2. In the left navigation pane, choose Security > WAF. Select the Whitelist Rules tab, and then click Create Rule.
3. Configure the settings as shown in the following example and click OK:
  - Rule Name: Enter a custom rule name, such as rule-allow-test-ip.
  - If requests match...: From the match field drop-down list, select Client IP. From the operator drop-down list, select is in. In the text box, enter 1.2.3.4.
  - Rule: Select Specific Rule Category/ID.
  - Rule Category: From the drop-down list, select Security Level.
  - Rule ID: Enter the Rule ID from Step 1.
Method 2: Adjust rule precedence
Because ESA executes rules sequentially, you can create a new security rule to lower the security level for test requests and give it a higher precedence than the blocking rule. This ensures the new rule is matched and takes effect first.
1. In the left navigation pane, choose Rules > Security Rules, and then click Create Rule.
2. Configure the settings as shown in the following example and click OK: In the If requests match... section, create a condition that matches the affected IP address, User-Agent, or request path. Then, in the Then execute... section, set the Security Level to Essentially Off or Off (Available in Enterprise Plans) to bypass security checks.
  - Rule Name: Enter a custom rule name, such as rule-allow-test-ip.
  - Apply to: Filtered Requests is selected by default. For the match field, select Client IP. For the operator, select is in. In the input box, enter 1.2.3.4.
  - Security Level: Select Essentially Off or Off (Available in Enterprise Plans) to bypass security checks.
3. On the Security Rules page, drag the icon to adjust the execution order of the rules. Place the rule-allow-test-ip rule before the original rule.

Availability

Feature	Free	Basic	Standard	Advanced	Enterprise
Number of security rules	5	10	25	50	125

FAQ

Types of challenges

When a request is identified as a potential threat, the system issues a challenge based on the configured security level:

JavaScript challenge: Injects a piece of JavaScript code into the client to verify that it is a real browser environment. This process is usually transparent to users but may affect API clients that do not support JavaScript.
CAPTCHA: Requires the user to complete an interactive task, such as a puzzle or slider verification, to prove they are human. This method interrupts the user's access flow.

Security rules and WAF rules

Security levels and WAF rules are independent features. A security level directs the system to automatically block or challenge a request based on the threat intelligence library. In contrast, WAF rules are custom rules that you define to block or challenge requests based on specific paths, parameters, or behaviors. This provides more granular security control.

References

Rule-related features vary in execution priority, rule behavior, and configuration scope. For more information, see How ESA rules take effect.