Cloudflare Rate Limiting

Cloudflare Rate Limiting protects against denial-of-service attacks, brute-force login attempts, and other types of abusive behavior targeting the application layer.


Overview

Cloudflare Rate Limiting is a feature that allows customers to identify and mitigate high request rates automatically, either for specific URLs or for an entire domain. 

Rate Limiting is an add-on service (available in all user plans) that when enabled, appears in the Firewall app of the Cloudflare dashboard. For subscription information, visit Cloudflare Pricing.

The most common uses for Rate Limiting are:

DDoS protection

Protect your site against a layer 7 (HTTP-based) DDoS attack that is either not stopped by I'm Under Attack mode or in situations when using I'm Under Attack mode is not desired; for example:

  • If you have legitimate automated traffic that would be unable to pass a challenge
  • When you do not wish to show an interstitial challenge page to your users

Brute-force attack protection

Protect your site from brute-force, password guessing login attempts.

Limited access to high-cost resources

Limit how often a client can access a resource that has a high processing cost on your origin; for example: forum searches, certain API calls, or other database-intensive actions.


How do I create a rule?

You can create a Rate Limiting rule via:


How many rules can I create?

It depends on your Cloudflare customer plan:

Plan # Rules
Free 1
Pro 10
Business 15
Enterprise 100

What happens when a rule activates?

Once a client (an individual IPv4 address or IPv6 /64 block) exceeds a rule threshold, requests will match the rule pattern and will no longer be sent to the origin web server. Clients receive an HTTP 429 with a Retry-After: X header to indicate how long their timeout period before they will be able to send requests again.

Request rates are calculated locally in individual Cloudflare points of presence (PoP). In practice, this should not matter as all requests from a given client will almost always route to the same PoP. The PoP may change due to routing modifications, but these are infrequent.

Cached resources are never rate-limited, even if they match a rule.

How will I be charged?

Rate Limiting charges are usage-based. Once you activate a rule, Cloudflare tracks and bills for requests that match the URL but that are not blocked but rather sent to your origin (unless you configure to rate limit on edge requests).  Your invoice is calculated at the end of your billing cycle.

Creating a new rule doesn't incur up-front costs. Usage-based billing is covered in detail in Billing for Cloudflare Rate Limiting.

What are the components of a Rate Limiting rule?

A Rate Limiting rule consists of three distinct elements as described below.

1. Request matching criteria

Incoming requests are matched based on:

The request path

For example:

  • http://example.com/example
  • http://example.com/example/*

This criteria is case insensitive and cannot match against a query string. An asterisk (*) will match any sequence of characters, including an empty sequence. For example, you'd use: 

  • *.example.com/* to match any path on any subdomain of example.com 
  • *example.com/example.html to match example.html on example.com or any subdomain of example.com
  • * to match any page on your site

Pattern matching takes any trailing slash "/" character into account.  A request for example.com/path is not the same as example.com/path/. As such, you should create rules for both if you want to match requests for that path and do not wish to use a wildcard. The one exception is the homepage: example.com will match requests for "GET /".

Additionally, patterns cannot match content after query strings (?) or anchors (#).

The request scheme

That is, HTTP or HTTPS. If none is specified, both are matched, and the rule will list _ALL_.

The request method

That is, POST or GET. If none is specified, all methods are matched, and the rule will list _ALL_.

The response code returned by the origin (optional)

For example, 401 or 403.

If you include this criteria and the rule triggers, subsequent requests from that client will be blocked regardless of which code is returned.  Since any of these codes cannot be seen without sending the request first, we must block all requests. 

2. Rate matching criteria

A rule can match on the number and time period of all requests coming from the same client:

Number of requests

Rules should specify a minimum of two requests, since a single request would match any request and should instead be handled by making the path unavailable completely; for example, by configuring the origin to return a 403.

Time period

Once a client exceeds the threshold specified in the time period, the rule will trigger. The periods available, by plan, are:

  • 1 second or 1 minute (Free and Pro)
  • 1 second, 1 minute, or 10 minutes (Business)
  • Any period between 1 second and 1 hour (Enterprise) 

3. Rule mitigation

Rule mitigations consist of:

Mitigation action

Options are based on the customer plan :

Action Description Available in
Block Cloudflare issues a 429 error when the threshold is exceeded. All plans
Challenge User has to pass a Google reCaptcha Challenge before proceeding. If successful, Cloudflare accepts the request. Otherwise, the request is blocked. Pro, Business, and Enterprise plans
JS Challenge User has to pass a Cloudflare Javascript Challenge before proceeding. If successful, Cloudflare accepts the request. Otherwise, the request is blocked.
Simulate Cloudflare does not block any requests but instead, logs them in Enterprise Log Share (ELS) as simulate.  You can use this option to test your rule before applying any of the other options in your live environment.

Time-out/ or ban period

This must be greater than the threshold, and attempting to set a timeout shorter than the threshold will result in the API automatically increasing the timeout to equal the threshold. The periods available, by plan, are:

  • 1 minute or 1 hour (Free and Pro)
  • 1 minute, 1 hour, or 24 hours (Business)
  • Any period between 10 seconds and 24 hours (Enterprise)

Custom error page

If you don't specify a custom error page, rate limiting visitors will get a default HTML page.

All paid plans can create a custom response to rate-limited clients, at most 32kB, in text, HTML via the Customize App.

In additon, Business and Enterprise customers can specify content-types and a response in the rule itself: text/plain and application/json.


What thresholds should I use?

All domains are different and the appropriate threshold depends on your typical traffic profile and needs.

Generally speaking, you can calculate a rough estimate of your normal traffic volume across your entire site by dividing the uncached requests over a 24-hour period by unique visitors for the same period. Then, divide that number by the estimated average length of a visit, in minutes, to give you a rough idea of average requests per client per minute. Then, multiply that value by 4 (or larger) to establish a rough per-minute threshold for your entire site. If you are unsure, using a higher value is typically fine--most attacks are an order of magnitude above typical traffic rates.

To obtain a more specific threshold, you may wish to compare request rates over multiple days, or review individual days and base thresholds off of peak traffic times.

For specific URLs, you should be able to calculate a similar value by reviewing your local access logs (or your Enterprise log share if you are an Enterprise customer)/unique clients logged for that URL. If you have not done so already, you should restore original IPs in your access logs.

You should set your threshold well above this request rate to account for clients that send more legitimate requests than both. While valid outlying client traffic patterns will vary per site, quadruple the average request rate is probably a good baseline to defend against attacks. You can then adjust the thresholds based on user reports and your own monitoring.

If you are actively under attack and are unsure how best to mitigate it, file a support ticket and Cloudflare Support will help you review your traffic and make recommendations on appropriate thresholds.


How can I see how rules have been applied?

Aggregate data about rate limiting can be seen in Analytics. For Enterprise customers, data on individual requests is available in ELS data.

Self-service (Free, Pro, Business plans) customers will not see specific clients/requests that are rate limited. They can only see the aggregate data available in Analytics.


Not finding what you need?

95% of questions can be answered using the search tool. This is the quickest way to get a response.

Powered by Zendesk