Understanding Directives and Conditions

Save PDF

Feedback

Last UpdatedMay 05, 2025
5 minute read

Directives are defined by the Actions of their title, and contain one or more Conditions.

Advanced Bot Protection provides six out-of-the-box Directives. They are summarized in the Directives table below.

A Condition is a container of rules, composed of Flags or code, against which the content of incoming requests are checked. If a match is found, then that Condition has been triggered and its Directive may be acted on.

If data in a request matches one of the Conditions in a Directive, then the Directive is activated and its Action taken. However, the order of the Directives in a Policy is critical. If data in a request matches a Condition in one Directive, and other data in the same request matches a different Condition in another Directive, then it is the higher Directive that is activated and any matches to Conditions in lower Directives are ignored - they may be logged, but their Actions are not carried out. For more information, see Understanding the Structure of the Policies and the Default Policy.

Activities with Directives

Search:

Activity	Description	For More Information, see...

Add new Directive	Add totally new Directives, name them as you wish and insert whichever Conditions you like. For most users, the six Directives supplied should be sufficient. You can add new Directives to non-Default Policies only.	Adding and Reordering Directives
Insert a Condition into a Directive	Insert a Condition into a Directive to expand the Directive's match capabilities.	Adding a Condition to a Directive
Configure the status of a Condition	A Condition's Status can be one of the following. You can toggle between them at any time: Active: A request with data that matched the Condition causes that Directive to be activated. Passive: A request with data that matched the Condition does not cause that Directive to be activated, but the match is logged. Disabled: A request with data that matched the Condition does not cause that Directive to be activated, and the match is not logged.	Configuring the Status of a Condition
Edit a Condition's Tags	You can assign Tags to a Condition. Tags are used for monitoring as there are graphs that show which Conditions are activated based on their tags. This allows the grouping of Conditions in meaningful ways for monitoring.	Editing a Condition's Tags
Edit a Condition	Edit the parameters and/or the Flags of certain types of Conditions.	Understanding and Editing Conditions
Move a Condition	You can move a Condition from one Directive to another. This is useful, for example, when you have checked a Condition for false positives in the captcha Directive, and now you want to move it to the block Directive.	Moving a Condition to a Different Directive.
Reorder Directives	Reorder Directives to change which Directives have priority.	Adding and Reordering Directives

Directives

Search:

Directive Name	Description	Recommended Placement in the Order

allow	If a Condition in the allow Directive is matched, the request is allowed through. Note that there are two allow Directives. The lower one is from the Account-Level Policy and applies to all Policies in the account.	Always at the top. If you have decided that a particular characteristic of a request demands its free passage, then no other characteristic should impede it. Note that this Action may still be overridden by a more stringent instruction from another CloudWAF service, if active.
block	Stop the request from getting to the target. Use the block Directive for Conditions that causes matches from data that cannot be anything but a bot. Note that there are two block Directives. The lower one is from the Account-Level Policy and applies to all Policies in the account.	Should be just below allow.
captcha_cleared	Once a captcha has been resolved, you do not want a characteristic that matches a Condition under captcha to activate a captcha afterward - at least for a time period. You can configure that time period.	Always above captcha.
captcha	Activates a captcha page. This Directive is used for the most frequently encountered suspicious request content.	Below block and captcha_cleared.
identify	There are cases where legitimate user traffic may look like a bot or some malicious intervention: a client has a slow connection a user has set the browser to not accept cookies a user has disabled his browser's javascript, or is using an ad-blocker, thus preventing Advanced Bot Protection's javascript challenge from fingerprinting the client To avoid impeding legitimate users, you want to give requests that might fall into the above categories an additional chance to identify themselves. With identify, you replace the page that the user requested with a page that explains why the user is getting blocked for a suitable time period, say 10 seconds. Thus a client with a slow connection will get the javascript loaded and then this Directive will not subsequently be activated. For the other cases, the users will view an explanation that they should either enable cookies, or disable the ad blocker, or enable javascript. If the client is a bot, then it can proceed no further. For a bot, identify is a block.	Below captcha.
tarpit	If a Condition in the tarpit Directive is matched, the response is never sent. This confounds attacks by leaving the bot waiting as long as possible, and thus draining the resources of the bot, lowering the number of requests that the bot is able to make. In contrast to delay, the tarpit Directive would cause enormous harm to a human user, so the tarpit Directive should include only those Conditions that are shown never to produce false positives. Tarpit can be used with CloudWAF, but cannot be used with any Connectors.	Below identify.
delay	If a Condition in the delay Directive is matched, the response is delayed by a few seconds. This confounds some types of attacks in the following way: A bot cannot be sure if the delay is due to a slow server or to a defense. It reduces the efficiency of attacks that rely on a sequence of requests - and many do. So if each request generates a second of latency, the advantages of an automated bot attack are greatly nullified. Delay confers these advantages without much harm to a human user, as a second latency is not perceived as unusual. So delay can be applied quite liberally. Delay can be used with CloudWAF, and with the following Connectors: F5 version 1.20.0 and later Cloudflare version 1.24.0 and later Openresty version 1.1.0 and later Lambda@edge coversion 1.23.0 and later Delay cannot be used with any version of Fastly.	Below identify.
monitor	If a Condition in the monitor Directive is matched, no Action is taken but the match is logged. The monitor Directive constitutes a staging area in which you can test Conditions to see if they are generating false positives. You can keep a Condition here, monitor the activity it generates, and refine it until it no longer generates false positives. Only then do you want to promote it to a different Directive and activate it.	Always at the bottom.

Was this topic helpful?

Like Dislike

Advanced Bot Protection

Filters

Source Type

Application Security

Data Security

Network Security

Application Performance

Product Versions

Hypervisor Installation

Document Type

Access

Product Area