Create a Rate Limiting Rule for an eCDN Zone

Configure a rate limiting rule to specify rate limits for requests that match a particular expression and then perform an action when requests reach those rate limits. Rate limiting rules improve B2C Commerce storefront availability, target specific traffic patterns and combat threats, such as bots.

1. In Business Manager, click App Launcher , and then select Administration | Sites | Embedded CDN Settings.
2. Locate the zone you want to configure, and select Configure Zone from the dropdown menu.
   
3. From the Security Rules tab, click New Rate Limiting Rule. You can also switch to a different zone from this tab. To switch zones, select another name from the Zone dropdown.
   
4. Enter a rule name. For example, "Rate limit requests from user_agent_x."
   
5. (Optional) If you want the rule to be active when you save it, select Enable Rule Upon Saving. If you’re not ready to activate the rule yet, you can create it first. When you’re ready, return to the Security Rules tab and enable your rule from the list.
6. Use the visual dropdown interface to enter the rule expression: select a field, operator, and value. To add conditional logic, use the And or Or buttons. You can also manually enter the expression by clicking Edit Expression.
7. To set the rate limit, specify the number of requests per period.
8. (Optional) To control whether cached asset requests count toward the rate limit, use the Also apply rate limiting to cached assets checkbox. This checkbox is selected by default, which matches prior behavior. Deselect it to exclude cached asset requests from the rule’s rate limit calculation.
9. (Optional) To define the request criteria that you want to rate limit, select Use Custom Counting Expression. This parameter defines when to increment the rate counter, which tracks the number of requests per period. When the rate counter exceeds the defined requests per period limit, the rule executes its action.
   1. If the counting expression isn’t provided, the counting expression is the same as the rule expression.
   2. The counting expression supports the option to rate limit based on HTTP response code, which isn’t possible using only the rule expression. For more examples of when to use a custom counting expression, see Rate Limiting Rules FAQ in the B2C Commerce API Developer Guide.
10. Matching Characteristics supports IP and IP with NAT support. The characteristics determine how to group incoming requests. Requests with the same values for the defined characteristics are grouped together and share a rate counter.
    1. For example, say that you use IP as the rule’s characteristics. If the rate of requests coming from a single IP address exceeds the defined limit, then further requests from that IP address are rate limited. Requests that come from other IP addresses do not share the same rate counter. In other words, the request rate of one IP address doesn’t affect the request rate of other IP addresses.
11. Select an action for the rule. For example, Block or Log. For more information, see Rule Actions in the B2C Commerce API Developer Guide.
12. To define how the action applies, select either Action for selected duration or Throttle requests over the maximum configured rate.
    1. Action for selected duration: After you meet the rate limiting criteria, apply the action to further requests matching the rule expression for the period specified by the duration.
    2. Throttle requests over the maximum configured rate: Throttle requests that exceed the configured maximum rate. The chosen action applies to those excess requests, while requests within the limit are still allowed.
13. If your rule uses Action for selected duration, select a duration from the dropdown menu.
14. Save the rule.

Bot and Leaked Credentials Expression Fields

When you author a rule expression, use any of these verified-bot and Leaked Credentials Detection fields in the Bot and Security section.

• cf.client.bot — Boolean. True when the request is a verified search-engine crawler (Googlebot, Bingbot, and so on). Returns the same result as cf.bot_management.verified_bot but, unlike the cf.bot_management.* fields, doesn't require a Cloudflare Bot Management entitlement. Use cf.client.bot for verified bot detection.
• cf.verified_bot_category — String. Identifies the specific purpose or type of the verified bot and, like cf.client.bot, is available without a Cloudflare Bot Management entitlement. Categories include Search Engine, Monitoring & Analytics, Advertising & Marketing, Page Preview, Academic Research, Security, Accessibility, Webhooks, Feed Fetcher, AI Crawler, Aggregator, and Other.
• cf.waf.auth_detected — Boolean. Cloudflare detected authentication material on the request.
• cf.waf.credential_check.password_leaked — Boolean. The submitted password appears in a known leak.
• cf.waf.credential_check.username_and_password_leaked — Boolean. The exact username and password pair appears in a known leak.
• cf.waf.credential_check.username_leaked — Boolean. The submitted username appears in a known leak.
• cf.waf.credential_check.username_password_similar — Boolean. The submitted password is highly similar to the submitted username.

Note 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).

Rate limit high-volume login POSTs but allow verified search crawlers through. Set 10 requests per 60 seconds per ip.src, with the managed_challenge action.

(http.request.uri.path contains "/Account-Login" and http.request.method eq "POST" and not cf.client.bot)

Rate Limit Login Requests After Leaked Credentials

Use Leaked Credentials Detection as a trigger for rate limiting on a path such as /Account-Login. After an IP submits leaked credentials that meet the threshold, issue a managed challenge to all subsequent login requests from that IP for the selected duration, whether those later requests contain leaked credentials.

This rule issues a Managed Challenge to all /Account-Login POST requests for 1 hour from an IP address that submitted two leaked credentials in the last minute.

• Rule name: Rate Limit Leaked Credentials
• Enable Rule Upon Saving: selected
• Rate limit: 2 requests per minute
• Use Custom Counting Expression: selected
• Matching Characteristics: IP with NAT support
• Action: Managed Challenge
• Action for selected duration: 1 hour

Rule expression:

(ends_with(http.request.uri.path, "/Account-Login") and http.request.method eq "POST")

Counting expression (include the login path and POST method so that leaked-credential submissions on other endpoints don't increment this counter):

(ends_with(http.request.uri.path, "/Account-Login") and http.request.method eq "POST" and cf.waf.credential_check.username_and_password_leaked)