Skip to content
Cloudflare Docs
Firewall
Cloudflare Docs
Firewall
Search icon (depiction of a magnifying glass)
GitHub icon
Visit Firewall on GitHub
Set theme to dark (⇧+D)

JSON object

Firewall rule example JSON response

A JSON response for the Firewall Rules API has this structure:

{  "id": "772bf1026a72c400ea576db1ffa16407",  "filter": {    "id": "6f58318e7fa2477a23112e8118c66f61",    "expression": "http.request.uri.path ~ \"^.*/wp-login.php$\" or http.request.uri.path ~ \"^.*/xmlrpc.php$\""    "paused": false,    "description": "WordPress login paths",    "ref": ""  },  "action": "challenge",  "priority": 1000,  "paused": false,  "description": "Protect blog login page",  "ref": ""}

This table summarizes the object properties:

NameDescriptionConstraints
id
String		A UUIDv4 identifier generated by Cloudflare.

Unique, read only

Length: 32 characters

filter
Object		A Cloudflare Filter object that contains an expression for evaluating this rule.
action
String		The action to take when a request satisfies the filter expression for this rule.log
bypass
allow
challenge
js_challenge
block
priority
Number		Determines the order of evaluation for the rule relative to others. Lower values indicate greater priority. Rules without a value are evaluated last. For guidance, see Avoiding priority conflicts.

Read only

Maximum length: 32

paused
Boolean		Returns true when the rule is not active. Use ref to enable/disable the rule.Default: false
description
String		An informative summary of the rule.Maximum length: 500 characters
ref
String		A short string for tagging rules.Maximum length: 50 characters

Avoiding priority conflicts

Priority plays a key role in configuring firewall rules because of the power of Cloudflare Filters in contrast to previous Cloudflare Firewall functionality.

With Cloudflare Filters, it is possible to construct conflicting rules such as:

  • allow requests from the office IP range, and
  • block requests with a specific user agent.

Requests from the office IP range using the user agent to block would trigger both rules, but we cannot both allow and block the request. To solve this problem, the Firewall Rules follow a strict ordering depending on action and priority.

Cloudflare prioritizes rules in descending order, such that priority 1 is first and rules with no priority are last. For rules of equal priority, Cloudflare orders them by action using the following order of precedence:

  1. log
  2. bypass
  3. allow
  4. challenge
  5. js_challenge
  6. block

In the example above if no priority is set, the allow request from the office IP range would apply because the allow action has a higher precedence than block.

To reduce the risk of unintended behavior, it's best to explicitly specify the desired priority for potentially conflicting rules.