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.

You can create rules at the corp (also known as account) or site (also known as workspace) level:

• Corp (account) rules: apply to all or multiple, specific sites (workspaces). You can create and manage these rules via the Corp Rules page in the Next-Gen WAF control panel. Corp (account) rules are not supported on the Essential platform.
• Site (workspace) rules: apply to one specific site (workspace). You can create and manage these rules via the Site Rules and Templated Rules pages in the Next-Gen WAF control panel and the Rules page in the Fastly control panel.

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 (account) rule usually takes precedence over a site (workspace) rule. The only time a corp (account) rule doesn't take precedence is when the site (workspace) 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 web application'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.

  IMPORTANT

  Advanced rate limiting rules are not supported on the Essential platform.

• 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.