Subscribe to receive notifications of new posts:

Firewall Rules - Priority and Ordering


3 min read

Firewall Rules are one of the best security features we released this year and have been an overwhelming success. Customers have been using Firewall Rules to solve interesting security related use cases; for example, advanced hotlink protection, restricting access to embargoed content (e.g. productId=1234), locking down sensitive API endpoints, and more.

One of the biggest pieces of feedback from the Cloudflare community, Twitter, and via customer support, has been around the order in which rules are actioned. By default, Firewall Rules have a default precedence, based on the actions set on the rule:

If two or more rules match a request, but have different actions, the above precedence will take effect. However, what happens if you've got a bad actor who needs to be blocked from your API, and you have other specific allow or challenge rules already created for their originating ASN or a perhaps one of your URLs? Once a Firewall Rule is matched, it will not continue processing other rule, unless you are using the Log action. Without a method of overriding the default precedence, you cannot easily achieve what's needed.

Today, we’re launching the ability for customers to change the ordering of their rules. The team at Cloudflare had a very long discussion about whether priority was the right solution, i.e. using an arbitrary number between 1 and 2,147,483,647 (int32) or whether customers should have a sequential list, and be able to drag and drop rules similarly to how Page Rules operates today.

After testing potential solutions with our users and learning about the wide range of use cases it was clear that we needed to offer customers the ability to choose.

In the Firewall Rules user interface, you should now have an additional button on the top right, shown here:

Priority Numbering

For customers managing a large number of rules, or predominantly using the API or Terraform for configuration, priority numbering is a great solution. Within Firewall Rules, as explained above, the default precedence is the final “conflict resolver”, providing a very useful way of grouping rules.

For example, one of the engineers behind Firewall Rules uses Priority to organise their rules into specific groups, e.g.

5000-9999 - Trusted IP addresses
10000-19999 - Blocking Rules for Bad Crawlers
20000-29999 - Blocking Rules for Abusive/Spam Users

Priority is an optional field on Rules and is available as an additional control to override the default precedence mentioned above. As this is the case, Cloudflare do not apply any default priority numbers on rules, and will be left blank.

Drag and Drop Ordering

Ordering is intuitive, being literally a drag and drop placement of rules in order of execution. See below for a quick demo of how straightforward the controls are:

There is currently a 200 rule limit with this method, so upon creating your 201st rule, you will be switched to Priority Numbering, automatically.

For more information on how Ordering and Priority Number operates, please visit our Firewall Rules documentation, found here.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.

Follow on X

Alex Cruz Farmer|@alexcf

Related posts

May 30, 2024 12:12 PM

Cloudflare acquires BastionZero to extend Zero Trust access to IT infrastructure

We’re excited to announce that BastionZero, a Zero Trust infrastructure access platform, has joined Cloudflare. This acquisition extends our Zero Trust Network Access (ZTNA) flows with native access management for infrastructure like servers, Kubernetes clusters, and databases...

April 12, 2024 1:00 PM

How we ensure Cloudflare customers aren't affected by Let's Encrypt's certificate chain change

Let’s Encrypt’s cross-signed chain will be expiring in September. This will affect legacy devices with outdated trust stores (Android versions 7.1.1 or older). To prevent this change from impacting customers, Cloudflare will shift Let’s Encrypt certificates upon renewal to use a different CA...