--- name: azion-apply-a-waf-rule-set-to-a-specific-cookie description: >- Run two WAF rule sets on one firewall, and score requests carrying a chosen cookie against the rule set that holds an exception. --- # Apply a WAF rule set to a specific cookie You can score requests that carry a chosen cookie against a different [Web Application Firewall (WAF)](/en/documentation/platform/firewall/#waf) rule set, from Azion Console. Use it when authenticated users, or an integrated third-party tool, need a policy the rest of your traffic does not. The setup holds three objects: - A primary rule set scores every request the firewall receives. - A secondary rule set carries an exception for one internal rule on the `Cookie` header. - Two [Rules Engine for Firewall](/en/documentation/platform/firewall/rules-engine/) rules select between them. For the scoring model behind them, refer to [Scoring and modes](/en/documentation/platform/firewall/waf/scoring-and-modes/). --- ## Prerequisites - A firewall with the WAF module turned on. Refer to [Set a firewall's main settings](/en/documentation/guides/application-security/firewall-and-waf/firewall-configure-main-settings/). - A workload bound to that firewall. Refer to [Bind a firewall to a workload](/en/documentation/guides/application-security/firewall-and-waf/firewall-protect-your-domain/). - Access to Azion Console. Refer to [How to access Azion Console](/en/documentation/guides/platform/account-and-billing/how-to-access-azion-console/). - The name and value of the cookie your application issues. --- ## Create the primary rule set This rule set scores the traffic that does not carry the cookie. To create it: 1. **Open the WAF Rules page** Access [Azion Console](https://console.azion.com/) > **Edge Libraries** > **WAF Rules**. 2. **Select + WAF Rule** 3. **Name the rule set** In the **General** section, enter a **Name**. For example: `storefront-primary`. 4. **Set the threat families** In the **Threat Type Configuration** section, set the **Sensitivity** of each threat family. 5. **Keep the Active switch turned on** 6. **Save the rule set** The rule set appears in **WAF Rules**. It scores nothing yet: a rule set inspects requests only after a Rules Engine rule names it. --- ## Create the secondary rule set This rule set scores the traffic that carries the cookie, so give it the same policy as the primary one. To create it: 1. **Select + WAF Rule** Still on the **WAF Rules** page, start a second rule set. 2. **Name the rule set** In the **General** section, enter a **Name**. For example: `storefront-cookie`. 3. **Repeat the threat families of the primary rule set** In the **Threat Type Configuration** section, set each **Sensitivity** to the value you gave the primary rule set. 4. **Keep the Active switch turned on** 5. **Save the rule set** The two rule sets now carry the same policy. The exception in the next section is what makes them differ. --- ## Add the cookie exception An exception stops one internal rule from firing in one place, and leaves it firing everywhere else. Azion Console calls an exception an allowed rule. To add one to the secondary rule set: 1. **Open the secondary rule set** In **WAF Rules**, select the rule set you created in the previous section. 2. **Select the Allowed Rules tab** 3. **Select + Allowed Rule** 4. **Select the rule to allow** In **Rule ID**, select the internal rule your cookie trips. This example uses `1005`, `Possible SQL Injection attack: MySQL keyword (|) found in Body, Path, Query String or Cookies`. 5. **Describe the exception** In **Description**, state why this rule is allowed. 6. **Set the path** In **Path**, enter `/` to cover the whole site, or a narrower path to limit the exception. 7. **Scope the exception to the cookie header** In **Condition**, select *Specific HTTP Header Name*, then enter `cookie` in **Name**. 8. **Leave Operator at its default** **Operator** defaults to *contains*, which reads **Name** as a literal string rather than as a regular expression. 9. **Save the allowed rule** The allowed rule appears in **Allowed Rules**, which lists its **Rule ID**, **Description**, **Path**, **Conditions**, and **Status**. > **Caution** > > Reopen the allowed rule and confirm that **Condition** reads *Specific HTTP Header Name* with `cookie` in **Name**. A condition that names no header covers every request header, and nothing reports the difference: the allowed rule saves either way, and the exception is wider than you meant. This exception relaxes one internal rule for the requests the secondary rule set scores. Every other rule in that rule set still scores them. A cookie is supplied by the client and can be forged. Anyone who learns the cookie name and value sends the same header and reaches the secondary rule set. Hold the exception to one **Rule ID** and to the narrowest **Path** your application allows. --- ## Apply the primary rule set to every request A Rules Engine rule selects requests by its criteria, and its `Set WAF` behavior names one rule set and one mode. A rule carries at most one `Set WAF` behavior, which is why this setup takes two rules. > **Caution** > > Key the criterion on the request URI, never on the query string. A criterion such as `Request Args` *matches* `.*` does not match a request without a query string, so it silently skips every `POST` whose payload sits in the body. To create the first rule: 1. **Open the firewall bound to your workload** In Azion Console, go to **Firewalls** and select that firewall. 2. **Select the Rules Engine tab** 3. **Select + Rule** 4. **Name the rule** Enter a name for the rule. For example: `Apply storefront-primary`. 5. **Set the criterion** In the **Criteria** section, select the `Request Uri` variable, the *starts with* comparison operator, and `/` as the argument. 6. **Add the Set WAF behavior** In the **Behaviors** section, select **Set WAF**, then select the primary rule set. 7. **Select Blocking as the mode** 8. **Save the rule** The firewall now scores every request it receives against the primary rule set. --- ## Apply the secondary rule set to requests with the cookie This rule reads the `Cookie` header and sends the requests that carry your cookie to the secondary rule set. A firewall processes its Rules Engine rules in the order they are arranged, so arrange this rule after the one you created in the previous section. To create it: 1. **Select + Rule** Still on the **Rules Engine** tab, start a second rule. 2. **Name the rule** Enter a name for the rule. For example: `Apply storefront-cookie`. 3. **Set the criterion** In the **Criteria** section, select the `Header Cookie` variable, the *matches* comparison operator, and `partner-access=b7c1f2e4` as the argument. 4. **Enter your own cookie** Replace `partner-access=b7c1f2e4` with the cookie your application issues. The *matches* operator reads the argument as a regular expression. 5. **Add the Set WAF behavior** In the **Behaviors** section, select **Set WAF**, then select the secondary rule set. 6. **Select Blocking as the mode** 7. **Save the rule** A request that carries the cookie is scored against the secondary rule set, so the allowed rule does not fire on its `Cookie` header, and every other rule in that rule set still scores it. A request without the cookie is scored against the primary rule set. --- ## Next steps - [WAF Exceptions](/en/documentation/platform/firewall/waf/custom-allowed-rules.md): Every field an exception carries, the fifteen conditions, and the Tuning screen. - [Tune a WAF rule set](/en/documentation/guides/application-security/firewall-and-waf/tune-waf.md): Read what a rule set matched and turn a false positive into an exception. - [Scoring and modes](/en/documentation/platform/firewall/waf/scoring-and-modes.md): The path a request travels, the scoring model, and what each mode does. - [Rules Engine for Firewall](/en/documentation/platform/firewall/rules-engine.md): Every criteria variable, comparison operator, and behavior a firewall rule can carry.