Security rules in Edge Security Acceleration (ESA) use a comprehensive threat intelligence library to protect your core services. By analyzing request characteristics like Client IP, Request Path, and User-Agent, ESA identifies potential threats and automatically initiates a challenge.
To set a consistent security level for all requests on the current site, see Security level.
Use cases
In website operations, core functionalities like admin backends, login interfaces, and payment APIs are frequent targets for automated tools, malicious crawlers, and cyberattacks. A single, fixed global protection policy is often ineffective: if it is too strict, it blocks legitimate users, and if it is too lenient, it fails to stop targeted attacks.
Creating fine-grained security rules lets you apply stricter security policies only to requests that access specific paths or exhibit suspicious characteristics. This provides targeted protection for your core services while minimizing the impact on regular users.
How security rules work
The ESA security rules are powered by an intelligent decision engine that matches request features against threat intelligence. When a user request reaches an ESA point of presence (POP), the system sequentially matches and processes it against the configured list of security rules.
This process involves three core mechanisms: threat detection, challenge validation, and security levels. The following sections describe these mechanisms.
Threat evaluation
ESA leverages Alibaba Cloud's comprehensive threat intelligence library, which aggregates global cyber threat data in real time.
Intelligence sources: Includes known malicious IP addresses, attack sources, botnets, and proxy services.
Detection dimensions: The system evaluates multiple aspects including IP reputation, geographic location, access patterns, and request attributes such as User-Agent. It then generates a dynamic threat score to determine the appropriate security level.
Security levels
Security levels define the sensitivity of threat detection and the strictness of countermeasures. Higher levels increase protection strength but may also increase friction for legitimate users.
Level | Recommended use cases | Description |
I'm Under Attack | Recommended only as an emergency measure during large-scale attacks. | Challenges all visitors to ensure maximum website availability. |
Low (Default) | For daily protection of websites with no history of targeted attacks. | Challenges IP addresses with the most severe threats. |
Medium | For websites with a history of volumetric attacks or requiring enhanced security. | Challenges IP addresses with elevated threat scores. |
High | For websites currently under attack or during critical events requiring heightened security. | Challenges any IP address exhibiting suspicious behavior. |
Essentially Off | Recommended only for temporary use when troubleshooting significant false positives. | Disables most security rules but retains essential platform-level protection against critical threats. |
Off (Available in Enterprise Plans) | Available only in Enterprise plans for debugging or special use cases. | Completely disables all active security features. |
Procedure
After creating a rule, ESA executes rules sequentially according to their Priorities, when processing user requests.
Create a security rule
In the ESA console, choose Websites, then click the target website in the Website column.
In the left navigation pane, choose .
Click Create Rule and enter a Rule Name.
In the If requests match... section, specify the user request features to match. In the Then execute... section, select the desired security level. For example, to
set a medium security level for requests to the hostname www.example.com, refer to the following settings:
(Optional) To adjust the rule’s execution priority, drag the
icon in the Order column or click Move to in the Actions column.
Verify the rule
After creating the security rule, if you create a rule to block abnormal requests from example.com, the response is a challenge page HTML.
When the challenge is passed, the response is the page content, and its header contains verified u_atoken and u_asession.
Handle exceptions and optimize rules
During rule execution, legitimate user IPs or API clients might be incorrectly challenged or blocked. Address such issues promptly. Consider this use case:
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
Add a WAF whitelist rule to allow known IP addresses, ensuring critical traffic remains unaffected.
On the Security Rules page, copy the corresponding Rule ID.
In the left navigation pane, choose . Click the Whitelist Rules tab, then click Create Rule.
Configure the settings as follows and click OK:
Rule Name: Enter a custom name, e.g.,
rule-allow-test-ip.If requests match...: Set the match field to
Client IP, operator tois in, and input1.2.3.4in the text box.Rule: Specific Rule Category/ID.
Rule Category: Security Level.
Rule ID: Paste the Rule ID copied in Step a from the Security Rules page.
Method 2: Adjust security rule priority
Since ESA executes rules in sequence, create a new rule to lower the security level for test requests. Assign this rule a higher priority (executed earlier) than the blocking rule so it takes effect first.
In the left navigation pane, go to , then click Create Rule.
Set up the rule as described below and click OK: In the If requests match... section, precisely match the affected IP, User-Agent, or path. In the Then execute... section, set Security Level to Essentially Off or Off (Available in Enterprise Plans) to bypass checks.
Rule Name: Use a descriptive name such as
rule-allow-test-ip.Apply to: Keep default Filtered Requests. For the match field, select
Client IP; for operator, chooseis in; enter1.2.3.4in the text box.Security Level: Essentially Off or Off (Available in Enterprise Plans).
On the Security Rules page, drag the
icon to reorder rules. Move the rule-allow-test-iprule above the original restrictive rule.
Availability
Security rules | Entrance | Pro | Premium | Enterprise |
Number of security rules | 5 | 25 | 50 | 125 |
FAQ
References
Rule-related features vary in execution priority, rule behavior, and configuration scope. For more information, see How ESA rules take effect.