About rules

Rules are configurations that define when the Next-Gen WAF should:

• allow, block, rate limit, or tag requests.
• prevent requests from being tagged with certain built-in signals.

The configurations can apply to multiple sites or individual sites:

• Corp-level rules: rules that apply to all sites or multiple, specific sites in your corp. You can create and manage corp rules via the Corp Rules page.
• Site-level rules: rules that apply to one specific site. You can create and manage site rules via the Site Rules and Templated Rules pages.

How rules work

Rules define how the Next-Gen WAF should handle requests to the web applications you're protecting. The Next-Gen WAF agent uses your active rules to determine what should happen to individual requests (e.g., allow, block, rate limit, or tag). The agent then performs any tagging decisions and sends the decisions to allow, block, or rate limit requests to the appropriate entity for you particular deployment method. The entity enacts the agent's decisions.

Rules precedence

When rules conflict, the Next-Gen WAF agent uses the following logic to determine which rule should take precedence:

• a rule with an allow action always takes precedence over a rule with a block action. For example, if you create a rule to block a range of IP addresses and a rule to allow one specific IP address within that range, requests from that IP address will be allowed because the allow rule takes precedence.
• a corp rule usually takes precedence over a site rule. The only time a corp rule doesn't take precedence over a site rule is when the site rule has an allow action.

Types of rules

There are four types of rules:

• Request rules: allow, block, or tag certain requests on an individual basis. For example, you could make a rule to block all requests with specific headers, requests to certain paths, or requests originating from specific IP addresses.
• Advanced rate limiting rules: block or tag requests from individual clients when a threshold (e.g., 100 requests in 1 minute) is passed. For example, you could make a rule to rate limit requests made to your site's login page to prevent account takeover attacks. If too many failed login attempts are made from a specific IP address, it's reasonable to suspect that person is trying to guess a password and break into another person's account. The rate limit rule will block that IP address from the login path for a set amount of time and prevent them from continuing to guess passwords.
• Signal exclusion rules: prevent requests from being tagged with certain signals. Signal exclusion rules help prevent false positives. For example, let's say you have an internal CMS where employees can post raw HTML. If employees try to post raw HTML that look like a Cross-Site Scripting (XSS) attack, their requests might get tagged with the XSS system signal and then blocked. To prevent false positives and your well-meaning employees from being accidentally blocked, you could create a signal exclusion rule to prevent requests that are coming from your VPN IP and post HTML from being tagged with the XSS signal.
• Templated rules: partially pre-constructed rules that can help you protect against Common Vulnerabilities and Exposures (CVE) and gain visibility into registrations, logins, and API requests. For example, you can enable the GraphQL API Query templated rule to track GraphQL API requests.