Use custom rules to control incoming traffic by setting up security policies based on request parameters. With custom rules, you have complete control over the rule expression, the allowed request field types, and the rule actions. This flexibility helps you create expressions that match your traffic needs. To create a custom rule in Business Manager, see Create a Custom Rule for an eCDN Zone in Salesforce Help.
Validation Overview
Rule Expression
The fields and operators supported in the rule expression are now consistent with what is offered with rate limiting rules. For more information, refer to Rule Expression in the eCDN Rate Limiting Rules guide.
Reference the verified-bot fields (cf.client.bot, cf.verified_bot_category) and the Leaked Credentials Detection fields (cf.waf.auth_detected, cf.waf.credential_check.password_leaked, cf.waf.credential_check.username_and_password_leaked, cf.waf.credential_check.username_leaked, cf.waf.credential_check.username_password_similar) in custom rule expressions. See Rule Expression for field descriptions.
The maximum length of a custom rule expression is 4096 characters.
Note
Leaked Credentials Detection and the SLAS login API: Leaked Credentials Detection scans the Authorization header for HTTP Basic Authentication credentials. Use the cf.waf.credential_check.* fields on SLAS login endpoints (for example, /shopper/auth/v1/organizations/{organizationId}/oauth2/login) and on storefront login endpoints (for example, /Account-Login).
Note
Challenge actions on SLAS login endpoints: Don’t apply js_challenge, legacy_captcha, or managed_challenge to SLAS login endpoints in a custom rule. SLAS login is API-based, not a browser page, so the endpoint cannot present an interactive challenge. Unless the storefront interprets the challenge response and presents a challenge to the shopper, a Challenge action behaves like a permanent block: a shopper whose credentials appear in a leak has no way to prove they are human and log in. Start the rule with the log action. While the rule is in log mode, monitor the traffic that matches it and assess whether those requests are safe to block—or, if the storefront can present a challenge, safe to Challenge.
Important
Rule Actions
The following rule actions are supported in the actions array:
block - Denies access to the requested site.
js_challenge - The client that made the request must pass a JavaScript Challenge before proceeding.
legacy_captcha - The client that made the request must pass an interactive challenge.
Legacy captcha still exist through the API. However, Salesforce recommends selecting the managed challenge response for a better user experience.
Note
managed_challenge - Depending on the characteristics of the request, the appropriate type of challenge is presented to the client.
log - Logs matching requests.
The following skip actions are also supported in the actions array:
skip_custom_rules - Skips all remaining custom rules (meaning custom rules with a lower priority are not evaluated).
skip_security_level - Skips Security Level.
skip_rate_limiting_rules - Skips rate limiting rules. See eCDN Rate Limiting Rules for related documentation.
skip_wafv2 - Skips WAFv2 managed rules. For additional information, see eCDN WAFv2.
If using the skip actions, the user can provide multiple skip actions in the array. Otherwise, the array includes only 1 rule action. See the following usage examples:
Custom rules are evaluated in the order they are listed in the response body. If a custom rule’s expression is matched, the action is executed.
The managed_challenge, js_challenge, legacy_captcha, block, and skip_custom_rules actions stop further custom rule evaluation and no other rules in the ruleset are evaluated.
The skip_security_level, skip_rate_limiting_rules, skip_wafv2, and log actions do not stop custom rule evaluation.
Position
When creating or updating a custom rule, users can provide a position attribute in the request body to insert the rule at a certain relative position in the ruleset. If the position is not provided during rule creation, the rule is added to the end of the ruleset by default. See the following usage examples:
1# Places the rule before rule <RULE_ID>23"position": {4 "before": "<RULE_ID>"5}67or89# Places the rule after rule <RULE_ID>1011"position": {12 "after": "<RULE_ID>"13}
Examples
The following examples show common custom rules. Combine and adjust them to your own business needs.
Challenge non-verified bots hitting the storefront cart endpoint:
Expression: (http.request.uri.path contains "/Cart-AddProduct" and not cf.client.bot)
Action: managed_challenge
Allow verified search engines through a country-based block:
Expression: (ip.src.country in {"CU" "IR"} and not cf.client.bot)
Action: block
Challenge login requests where the submitted password matches a known leak:
Expression: (http.request.uri.path contains "/Account-Login" and cf.waf.credential_check.password_leaked)
Action: managed_challenge
Create a Custom Rule
This endpoint creates a custom rule in the specified zone.
The description, expression, and actions attributes are required.
The enabled and position attributes are optional.
Refer to the Validation Overview section for more information on input validation
Newly created rules are enabled by default and added to the end of the ruleset unless specified otherwise. A maximum of 500 custom rules is allowed.
This endpoint updates the order of all existing custom rules. The user provides an array of ruleIds that represents the new rule order. The array must contain exactly all of the existing custom rule ruleIds.