Web Application Firewall:Custom rules

Step 1: Configure template type

On the Core Web Protection page, find the Custom Rule section and click Create Template. In the Create Template panel, configure the following parameters.

• Template Name: Enter a name for the template.

• Save as Default Template: You can set only one default template in the custom rule module, and you can set it only when you create a new template.

  • Yes: You do not need to configure an Apply To. When the template is created, it applies to all protected objects and object groups by default. It also automatically applies to new objects that are added later. You can manually exclude specific objects by setting their status to 'Inactive'.

  • No: You must set the Apply To to manually specify the protected objects or object groups.

Step 2: Add protection rules

In the Rule Configuration area, click Create Rule and configure the following parameters.

• Rule Name: Enter a name for the rule.

• Match Condition: Defines the request characteristics that the rule inspects. Click Add Condition to add a condition. Each condition consists of a Match Field, Logical Operator, and Match Content. The following table provides configuration examples.

  Note

  If a rule contains multiple conditions, a request must match all conditions (a logical AND relationship) to trigger the rule. You cannot configure a logical OR relationship between conditions. To block requests that match any one of several keywords or characteristics (for example, keyword A or keyword B), create a separate protection rule for each condition. For more information about match fields and logical operators, see Match conditions.

  Match Field	Logical Operator	Match Content	Description
  URI Path	Contains	/login.php	The rule matches if the request path contains /login.php.
  IP	Belongs To	192.1.XX.XX	The rule matches if the client IP address is 192.1.XX.XX.

  Note

  Complex match rules

  1. Multi-value matching logic and limits
  To apply the same rule to multiple API endpoints, you can use logical operators that support multiple values, such as Contains One of Multiple Values, Equals One of Multiple Values, Does Not Contain Any Value, or Does Not Equal Any Value. The configuration requirements are as follows:
  

  • Delimiter: You must use a comma (,) to separate multiple match values. The system splits the values by commas and processes them independently.

  • Quantity and deduplication: You can enter up to 50 values. Duplicate values are not allowed.

  2. Handling special characters
  If the match content contains a comma (for example, in some User-Agent strings), the system may misinterpret it as a multi-value delimiter, causing the match to fail. In this case, do not use multi-value logical operators. We recommend the following alternatives:
  

  • Regular expression matching: Matches content using a regular expression and treats commas as literal characters.

  • Single rule: Create a separate rule for the specific string and use a single-value logical operator.

  3. Regex application examples

  • Match a specific version number range: To match Chrome browser versions between 100 and 200, set the match field to User-Agent, the logical operator to Regex Match, and the match content to Chrome/(1[0-9]{2}|200)\..

  • Block multiple URL encodings: To block requests that are URL-encoded multiple times, for example, where % is encoded as \x25, set the logical operator to "Regex Match" and the match content to \x25.*\x25.

  4. Recommendations for production environments
  When you configure complex match conditions like regular expressions in a production environment, we recommend that you first use the Monitor action or a canary test to verify the rule's behavior. After you confirm that there are no issues, you can apply the rule to all traffic.
  

• Protection Rule Type: Three types are supported: Access Control, Rate Limiting, and Extension Execution.

  • Access Control: Ideal for scenarios that require precise control over specific types of requests.

  • Rate Limiting: Ideal for scenarios that require protection based on access frequency, such as preventing credential stuffing and brute-force attacks. This feature is available only on subscription (Enterprise or Ultimate Edition) and pay-as-you-go WAF instances.

  • Extension Execution: Ideal for personalized security scenarios that require custom Lua scripts to implement complex business logic. We recommend that you configure extensions first.

  Access control

  Configure an access control rule to perform a specified action on individual requests that meet specific conditions.

  Rate limiting

  Configure a rate limiting rule to restrict excessive access from clients.

  • Rate detection conditions: If the number of times a single Statistical Object matches the rule within the specified Statistical Interval (Seconds) exceeds the configured Threshold (Times), WAF triggers the blacklist action.

    Parameter	Description
    Statistical Object	Select the object for which to measure request frequency. Options include: IP: Measures the request frequency from a single IP address. If you deploy a Layer 7 proxy, such as a CDN or Anti-DDoS, in front of WAF, ensure that you set the Is a Layer 7 proxy (such as Anti-DDoS/CDN) deployed before WAF? parameter to Yes when you add the asset to WAF. Incorrect configuration prevents WAF from obtaining the real client IP address, and IP-based rules will fail. Custom Header: Groups requests by the value of a custom request header, such as Referer, and measures the request frequency for each group with the same header value within the specified time period. Custom Parameter: Measures the request frequency for requests that contain a specific parameter in the URL. For example, if the parameter is user_id, WAF measures the frequency of requests with the same user_id value. Custom Cookie: Measures the frequency of HTTP requests that contain a specific cookie within the specified time period. For example, if the custom cookie name is User, WAF counts the occurrences of each User value within the time period. Session: WAF establishes a session ID by setting a cookie named acw_tc in the response and measures client request frequency based on this cookie's value. Account: Measures the request frequency from the same account. You must configure User Identification on the Protected Objects page before you can use this option. For more information, see Configure protected objects and protected object groups.
    Statistical Interval (Seconds)	Set the statistical period in seconds.
    Threshold (Times)	Set the maximum number of times the Statistical Object is allowed to match the Match Condition within the Statistical Interval (Seconds).

  • Status code detection conditions: If the Quantity or Percentage (%) of responses with a specific Status Code exceeds the configured threshold, WAF triggers the blacklist action. If you enable status code detection, the statistical object must meet both rate detection and status code conditions to trigger the action.

    Parameter	Description
    Status Code	Set the status code to count.
    Quantity	Set the maximum number of times the specified Status Code can appear in responses within the statistical period.
    Percentage (%)	Set the maximum percentage of responses with the specified Status Code within the statistical period.

  • Blacklist action conditions: Adds statistical objects that meet the preceding detection conditions to a blacklist. For the duration of the Timeout Period, WAF applies the configured Rule Action to requests from the blacklisted object that fall within the Apply To scope.

    Parameter	Description
    Apply To	Set the scope for the blacklist action. Options include: Current Match Condition: The action applies only to requests that meet the Match Condition of the current rule. Protected Object: The action applies to all requests from the statistical object, such as an IP address, to the current protected object.
    Timeout Period	Set the duration of the blacklist action. Unit: seconds. Value range: 60 to 86400.

  Extension execution

  Select from your configured extension rules to implement personalized security controls.

  Note

  Extension Execution rules support only two rule actions: Block and Log.

• Rule Action: Select the action to perform when a request matches the rule.

  Parameter	Description
  JavaScript Validation	WAF returns a JavaScript snippet to the client for validation. A standard browser automatically executes this code. If the client's browser executes the code successfully, WAF allows all requests from that client for a period (30 minutes by default). Otherwise, WAF blocks the requests.
  Block	Blocks requests that match the rule and returns a block response page to the client. Note WAF uses a default block page. You can also use the Custom Response feature to customize the block page.
  Log	Allows requests that match the rule but records the match in the logs. When you test a new rule, you can first use the Log mode to analyze WAF logs and confirm that the rule does not block legitimate requests, and then switch to a different rule action.
  CAPTCHA	WAF returns a CAPTCHA page to the client. If the client successfully completes the CAPTCHA, WAF allows all requests from that client for a period (30 minutes by default). Otherwise, WAF blocks the requests. Note For a WAF instance that uses the pay-as-you-go billing method, this rule action incurs additional fees. For more information, see Pay-as-you-go billing details.
  Strict CAPTCHA	WAF returns a CAPTCHA page to the client. If the client successfully completes the CAPTCHA, WAF allows the request. Otherwise, WAF blocks it. In this mode, every request from the client that matches this rule requires CAPTCHA verification. Note For a WAF instance that uses the pay-as-you-go billing method, this rule action incurs additional fees. For more information, see Pay-as-you-go billing details.

  Note

  • The CAPTCHA action is available only on subscription (Enterprise or Ultimate Edition) and pay-as-you-go WAF instances.

  • JavaScript Validation and CAPTCHA actions apply only to synchronous requests. For asynchronous requests, such as those made with XMLHttpRequest or the Fetch API, you must inject the Web SDK. Otherwise, these features will not work correctly. For more information, see the JavaScript validation and CAPTCHA sections in Bot management.

  • After you enable JavaScript Validation or CAPTCHA and the client passes the verification, WAF uses Set-Cookie to set a cookie named acw_sc__v2 (for JavaScript Validation) or acw_sc__v3 (for CAPTCHA) in the response header. The client then includes this identifier in the Cookie header of subsequent requests.

• Advanced Settings (Optional): The following advanced features are available only for WAF instances of Enterprise Edition or Ultimate Edition that use the subscription billing method, and for pay-as-you-go WAF instances.

  Parameter	Description
  Canary Rule	Configure the percentage of traffic to which the rule applies, based on a specified dimension. After you enable a canary rule, you must also set the Dimension and Canary Release Proportion. Valid values for Dimension are IP, Custom Header, Custom Parameter, Custom Cookie, and Session. Note A canary rule takes effect based on the configured Dimension, rather than being randomly applied to a percentage of all requests. For example, if you set Dimension to IP and Canary Release Proportion to 10%, WAF selects approximately 10% of all IP addresses. WAF then applies the rule to all requests from the selected IP addresses, not to a random 10% of all requests.
  Effective Mode	Permanently Effective (Default): The rule is always in effect when the protection template is enabled. Fixed Schedule: The rule is in effect only during a specified time period. Recurring Schedule: The rule is in effect only during a specified recurring time cycle.

Step 3: Set apply-to objects

In the Apply To area, select the protected objects and protected object groups to which you want to apply the template.

How the template is applied depends on the configuration you made in Step 1:

• If you set the template as the default protection template: You do not need to configure apply-to objects. The template is applied to all existing and new protected objects and protected object groups by default. You can manually exclude specific objects by setting their status to "Not Applied".

• If you did not set the template as the default protection template: You must manually specify the protected objects and protected object groups to which the template applies.

Why is my rule not working?

If a configured WAF custom rule does not work as expected, or if the number of intercepted requests is significantly lower than expected, we recommend that you systematically troubleshoot the issue in the following areas.

Check basic configuration and status

1. Verify protected object association: Verify that you have correctly created and associated the custom rule template with the target Protected Object/Group (such as an ALB instance or a domain name). Ensure its status is Effective; otherwise, WAF cannot deliver and execute the rule.

2. Check the template and rule status: Check that both the protection template's Status switch and the specific rule's Status switch are turned on. If either switch is off, the corresponding rule will be inactive.

3. Verify the rule action: Confirm that the rule's Rule Action is set to something other than Log. The Log action only records events and does not block requests.

Validate match conditions and logic

1. Match condition accuracy: Thoroughly check whether the rule's Match Field, Logical Operator, and Match Content correctly match the target requests. If you use a regular expression, strictly verify that you wrote escape characters correctly.

2. Strategy for dynamic paths: If the target path contains dynamically generated random segments (such as random parameters or IDs), we recommend setting the match field to URI Path and using the Contains logical operator to match only the fixed, unchanging string in the path. Avoid matching the full path, as dynamic changes can cause the rule to fail.

3. Handling missing headers: For request header fields that might be missing, such as Referer or User-Agent, note that "the field's value is empty" and "the field does not exist in the request header" are two different logical states. We recommend configuring conditions for both logical states to prevent the rule from failing due to an unhandled state.

Check rule priority and trigger conditions

1. Other rules may take precedence: Check for other configured protection rules or modules. For example, if an allowlist rule is configured, a request might pass before your block rule can evaluate it.

2. Rate limiting with status code conditions: If you configure a Rate Limiting rule and enable status code detection, WAF triggers the rule only if the statistical object meets both the "access frequency threshold" and "status code characteristics" conditions within the statistical period. You need to confirm that the origin server actually returns the specified status code (such as 404) for the relevant requests. Otherwise, WAF will not trigger the rule even if the access frequency reaches the threshold.

Rate limit a domain on a shared instance

Rate limiting rules restrict the request frequency of a single statistical object based on the protected object. If a single cloud service instance handles traffic for multiple domains, WAF aggregates the access frequency across all domains for statistical purposes. If you need to limit the access frequency for only a specific domain, you can use one of the following methods:

• Add the domain as a WAF protected object and apply the rate limiting rule to that object. For more information, see Configure protected objects and protected object groups.

• In the Match Condition of the rate limiting rule, use the Host field to specify the domain for which you want to limit access frequency.

Troubleshooting the body parameter match field

The likely reason is that the match content is too short. When you use the Body Parameter field, make sure the match content is at least five characters long. Otherwise, WAF cannot detect the traffic.

How to protect against nighttime attacks

For services with minimal legitimate traffic at night, you can configure stricter protection rules to defend against attacks. To do this, set the rule's Effective Mode to Recurring Schedule and select the correct Time Zone to apply precise protection during nighttime hours.

If your service does not cater to users in specific regions (for example, if it only serves domestic users), you can also configure regional blocking rules to directly block access requests from those regions, thereby blocking anomalous traffic.

Allow specific requests and block others

Configuration logic for allowing specific requests and blocking all others

WAF custom rules use a "match and trigger" logic, which does not directly support a positive allowlist model of "allow only specified requests, block all others". To implement this security policy, you must use reverse logic: "block all requests that do not match the allow criteria". For a specific configuration method, see Restrict admin panel access to specific IP addresses.

Differences between WAF and Cloud Firewall ACLs

WAF differs fundamentally from Cloud Firewall ACLs and ECS security groups in its defense model:

• Cloud Firewall ACL: Configured based on fixed and enumerable "business intents". For example, you can restrict an internal database to allow access only from specific application server IP addresses. It uses a "deny all by default, allow by exception" strategy to precisely reduce the network attack surface.

• WAF: Provides defense based on signatures and behavior, primarily for HTTP/HTTPS requests. Web application traffic is highly complex, involving numerous dynamic requests and user interactions. If you were to adopt a "deny all, allow by exception" strategy in WAF, you would need to enumerate all legitimate request characteristics, such as URLs, parameters, and headers. This strategy is not only difficult to implement but also extremely costly to maintain.

Recommended fine-grained WAF strategies

Given these differences, we do not recommend configuring a global "block all, allow specific" rule in WAF. Instead, adopt the following fine-grained configuration strategy:

1. Precise access control: For sensitive paths like admin panels or core API endpoints, configure precise access control rules based on IP address, User-Agent, or specific headers to enforce strict access control.

2. Baseline protection: For regular traffic from the public, rely on WAF's Core Web Protection rules and CC protection modules to identify and block known attack patterns and anomalous behaviors, rather than using a blanket block.

3. Continuous tuning: Regularly analyze WAF event logs. Continuously iterate and refine your access control rules based on changes in business traffic and the threat landscape to ensure a balance between security and business availability.

Using the contains operator to avoid duplicate rules

When you set the match field to URI Path and the logical operator to Contains, a request matches if the specified string appears anywhere in the request path.

Example: If you enter /resources/author/ as the match content, it can match multilingual paths such as /cn/resources/author/ and /en/resources/author/.

Use case: For multi-level directories or multilingual sites that share a common, fixed path segment, this method can effectively reduce the need for duplicate rules.