Cloudflare helps customers control their own traffic at the edge. One of two products that we introduced to empower customers to do so is Cloudflare Rate Limiting*.
CC BY 2.0 image by Brian Hefele
Rate Limiting allows a customer to rate limit, shape or block traffic based on the rate of requests per client IP address, cookie, authentication token, or other attributes of the request. Traffic can be controlled on a per-URI (with wildcards for greater flexibility) basis giving pinpoint control over a website, application, or API.
Cloudflare has been dogfooding Rate Limiting to add more granular controls against Layer 7 DOS and brute-force attacks. For example, we've experienced attacks on cloudflare.com from more than 4,000 IP addresses sending 600,000+ requests in 5 minutes to the same URL but with random parameters. These types of attacks send large volumes of HTTP requests intended to bring down our site or to crack login passwords.
Rate Limiting protects websites and APIs from similar types of bad traffic. By leveraging our massive network, we are able to process and enforce rate limiting near the client, shielding the customer's application from unnecessary load.
To make this more concrete, let's look at a live demonstration rule for cloudflare.com. Multiple rules may be used and combined to great effect -- this is just a limited example.
Read on, and then test it yourself.
Creating the rule
Imagine an endpoint that is resource intensive. To maintain availability, we want to protect it from high-volume request rates - like those from an aggressive bot or attacker.
Rate Limiting allows for * wildcards to give more flexibility. An API with multiple endpoints might use a pattern of
With that pattern, all resources under
/v2 would be protected by the same rule.
We set this demonstration rule to 10 requests per minute, which is too sensitive for a real web application, but allows a curious user refreshing their browser ten times to see Rate Limiting in action.
We set this value to
block which means that once an IP addresses triggers a rule, all traffic from that IP address will be blocked at the edge and served with a default 429 HTTP error code.
Other possible choices include
simulate which means no action taken, but analytics would indicate which requests would have been mitigated to help customers evaluate the potential impact of a given rule.
This is the duration of the mitigation once the rule has been triggered. In this example, an offending IP address will be blocked for 1 minute.
Response body type
This type was set to
HTML in the demo so that Rate Limiting returns a web page to mitigated requests. For an API endpoint, the response body type could return JSON.
The response body can be anything you want. Refresh the link below 10 times very quickly to see our choice for this demonstration rule.
Other possible configurations
We could have specified a Method. If we only cared to rate limit POST requests, we could adjust the rule to do so. This rule could be used for a login page where high frequency of POSTs by the same IP is potentially suspicious.
We also could have specified a Response Code. If we only wanted to rate limit IPs which were consistently failing to authenticate, we could create the rule to trigger only after a certain threshold of 403’s have been served. Once an IP is flagged, perhaps because it was pounding a login endpoint with incorrect credentials, that client IP could be blocked from hitting either that endpoint or the whole site.
We will expand the matching criteria, such as adding headers or cookies. We will also extend the mitigation options to include CAPTCHA or other challenges. This will give our users even more flexibility and power to protect their websites and API endpoints.
We'd love to have you try Rate Limiting. Read more and sign up for Early Access.
**Note: This post was updated 4/13/17 to reflect the current product name. All references to Traffic Control have been changed to Rate Limiting.*