--- name: azion-apply-a-rule-set-to-every-request description: >- Create the firewall rule whose Set WAF behavior hands every request to one rule set, from Azion Console, the Azion CLI, or the API. --- # Apply a rule set to every request You can create the [Rules Engine for Firewall](/en/documentation/platform/firewall/rules-engine/) rule that applies a rule set to every request from Azion Console, the Azion CLI, or the API. A rule set scores nothing until a rule names it, and the criterion below skips no request. --- ## Prerequisites ### Console - A firewall bound to your workload, with WAF turned on in its main settings. - A rule set to apply, such as `storefront-waf`. To create one, refer to [Create a rule set at medium sensitivity](/en/documentation/guides/application-security/firewall-and-waf/rule-set-medium/). ### CLI - A firewall bound to your workload, with WAF turned on in its main settings. - A rule set to apply, such as `storefront-waf`. To create one, refer to [Create a rule set at medium sensitivity](/en/documentation/guides/application-security/firewall-and-waf/rule-set-medium/). - The [Azion CLI](/en/documentation/devtools/cli/) installed and a configured personal token. ### API - A firewall bound to your workload, with WAF turned on in its main settings. - A rule set to apply, such as `storefront-waf`. To create one, refer to [Create a rule set at medium sensitivity](/en/documentation/guides/application-security/firewall-and-waf/rule-set-medium/). - A personal token. --- ## Create the rule ### Console To create the rule from Azion Console: 1. **Open the firewall bound to your workload** Access [Azion Console](https://console.azion.com/) > **Firewalls**, then select that firewall. 2. **Select the Rules Engine tab** 3. **Select + Rule** 4. **Name the rule** Enter `Apply storefront-waf` as the name. 5. **Set the criterion** In the **Criteria** section, select the `Request Uri` variable, the *starts with* operator, and `/` as the argument. 6. **Add the Set WAF behavior** In the **Behaviors** section, select **Set WAF**, then `storefront-waf` as the rule set and *Blocking* as the mode. 7. **Save the rule** The rule hands every request the firewall receives to `storefront-waf` in blocking mode. For the same rule with the threat families and the mode left open, refer to [Create and apply a WAF rule set](/en/documentation/guides/application-security/firewall-and-waf/create-waf-rule-set/). ### CLI To create the rule with the Azion CLI, save it as `rule.json`, with the id of your rule set in `waf_id`: ```json { "name": "Apply storefront-waf", "active": true, "criteria": [ [ { "conditional": "if", "variable": "${request_uri}", "operator": "starts_with", "argument": "/" } ] ], "behaviors": [ { "type": "set_waf", "attributes": { "waf_id": 12349, "mode": "blocking" } } ] } ``` Then create the rule from the file: ```bash azion create firewall-rule --firewall-id --file rule.json ``` ```text Created Firewall Rule with ID 123457 ``` The output reports the id of the new rule. ### API Save the rule as `rule.json`, with the id of your rule set in `waf_id`: ```json { "name": "Apply storefront-waf", "active": true, "criteria": [ [ { "conditional": "if", "variable": "${request_uri}", "operator": "starts_with", "argument": "/" } ] ], "behaviors": [ { "type": "set_waf", "attributes": { "waf_id": 12349, "mode": "blocking" } } ] } ``` Send a `POST` request to the firewall's request rules endpoint, with the file as the body: ```bash curl --request POST \ --url https://api.azion.com/v4/workspace/firewalls//request_rules \ --header 'Accept: application/json' \ --header 'Authorization: Token [TOKEN VALUE]' \ --header 'Content-Type: application/json' \ --data @rule.json ``` The API answers `202` and returns the rule with two keys it assigned: an empty `description` and the `order` the rule holds among the rules of that firewall. > **Note** > > `criteria` is a list of lists, and a rule carries at most one `Set WAF` behavior. `mode` is required on that behavior: a `set_waf` behavior sent without it is refused with `400` and the error `10059 Required Field`, pointing at `/data/behaviors/0/attributes/mode`. Key the criterion on `${request_uri}`, not on the query string. An empty variable does not match, so `${request_args}` with the `matches` operator and `.*` skips every request carrying no query string, including a `POST` whose payload sits entirely in the body. --- ## Apply a rule set to selected paths in Logging A rule set can score only the paths that need it, such as a login form or an API, and start in *Logging*. *Logging* scores, records, and serves each request, so the records show what the rule set flags on your own traffic before it refuses anything. The rule matches the paths, not the query string, because a form posts its fields in the body. The example creates the rule set `auth-waf`, with every threat family at `medium`, and applies it to `/login`, `/signup`, and `/checkout`. A single criterion on `/` matches every request. Replace each value with your own. ### Console To create the rule set and apply it: 1. **Create the rule set** Access [Azion Console](https://console.azion.com/) > **Edge Libraries** > **WAF Rules**, select **+ WAF Rule**, enter `auth-waf` as the **Name**, keep every family at *Sensitivity Medium*, and select **Save**. 2. **Create the rule** In the firewall's **Rules Engine** tab, select **+ Rule** and enter `auth - apply auth-waf`. 3. **Match the three paths** In the **Criteria** section, select `Request Uri`, *starts with*, and `/login`. Add two criteria joined by **Or**: `/signup` and `/checkout`. 4. **Add the Set WAF behavior** In the **Behaviors** section, select **Set WAF**, then `auth-waf` and *Logging*. 5. **Select Save** ### CLI This guide documents this task in Azion Console and in the API. Follow the [API procedure](?interface=api#apply-a-rule-set-to-selected-paths-in-logging). ### API To create the rule set, send the body of the [WAF quickstart](/en/documentation/platform/firewall/waf/quickstart/) with `"name": "auth-waf"`, to `POST https://api.azion.com/v4/workspace/wafs`. The API answers `202` with the rule set's `id`. To apply it: ```bash curl --request POST \ --url https://api.azion.com/v4/workspace/firewalls//request_rules \ --header 'Authorization: Token ' \ --header 'Content-Type: application/json' \ --data '{ "name": "auth - apply auth-waf", "active": true, "criteria": [ [ { "variable": "${request_uri}", "conditional": "if", "operator": "starts_with", "argument": "/login" }, { "variable": "${request_uri}", "conditional": "or", "operator": "starts_with", "argument": "/signup" }, { "variable": "${request_uri}", "conditional": "or", "operator": "starts_with", "argument": "/checkout" } ] ], "behaviors": [{ "type": "set_waf", "attributes": { "waf_id": , "mode": "logging" } }] }' ``` The API answers `202` with a `state` of `pending` and the rule as it was stored. Requests to the three paths are scored for attack payloads, and what would be blocked is recorded. Move the rule to *Blocking* once 3 days of **Tuning** hold no request that should have been served, as [Switch a rule set to blocking](/en/documentation/guides/application-security/firewall-and-waf/switch-to-blocking/) describes. To confirm the rule scores the paths, send an injection-shaped query string to one of them: ```bash curl -i "https://www.example.com/login?q=1%27%20OR%20%271%27%3D%271" ``` In *Logging*, the page loads. After the switch to *Blocking*, the same request receives: ```text HTTP/2 400 ``` The response's `x-azion-request-id` finds the request's WAF record. For the lookup, refer to [Find the WAF score of a blocked request](/en/documentation/guides/application-security/firewall-and-waf/how-to-find-waf-score/). In the [Protect web applications from OWASP Top 10 and zero-day attacks](/en/documentation/use-cases/secure-applications-and-networks/protect-web-applications-from-owasp-top-10-and-zero-day-attacks/) use case, this section takes these values: | Setting | Value | | --------- | --------------------------------------------------------------------------------------------------- | | Rule | `webapp - apply webapp-waf` | | Criterion | `Request Uri` *starts with* `/` | | Behavior | **Set WAF** with `webapp-waf`, in *Logging*. The API requires the mode, sent as `"mode": "logging"` | The rule set scores every request the use case's network rule lets through, and records what would have been blocked. To read those records and turn a false positive into an exception, refer to [Tune a WAF rule set](/en/documentation/guides/application-security/firewall-and-waf/tune-waf/). In the [Protect public APIs from abuse](/en/documentation/use-cases/secure-applications-and-networks/protect-public-apis-from-abuse/) use case, this section takes these values: | Setting | Value | | --------- | -------------------------------------------------------------------------------- | | Rule | `api - apply api-waf` | | Criterion | `Request Uri` *starts with* `/v1/` | | Behavior | **Set WAF** with `api-waf`, in *Logging*, sent in the API as `"mode": "logging"` | Every request to `/v1/` is scored against `api-waf`, and what would be blocked is recorded. The [Block account takeover on login and checkout flows](/en/documentation/use-cases/secure-applications-and-networks/block-account-takeover-on-login-and-checkout-flows/) use case uses the values of this example. In the [Protect web applications from OWASP Top 10 and zero-day attacks](/en/documentation/use-cases/secure-applications-and-networks/protect-web-applications-from-owasp-top-10-and-zero-day-attacks/) use case, expect: - **WAF scores an attack pattern.** From an address that is not listed, a request with an injection-shaped query string, `https://www.example.com/?q=1%27%20OR%20%271%27%3D%271`, is answered as usual in *Logging*, and receives `HTTP/2 400` after the switch to *Blocking*. The response's `x-azion-request-id` finds the request in the `workloadEvents` dataset of Real-Time Events, where `wafMatch` names the internal rules that matched, `1009` and `1013` for this query string. For the lookup, refer to [Find the WAF score of a blocked request](/en/documentation/guides/application-security/firewall-and-waf/how-to-find-waf-score/). In the [Protect public APIs from abuse](/en/documentation/use-cases/secure-applications-and-networks/protect-public-apis-from-abuse/) use case, expect: - **WAF scores an attack pattern.** With a valid token, a request with an injection-shaped query string, `https://api.example.com/v1/orders?q=1%27%20OR%20%271%27%3D%271`, is answered as usual in *Logging*, and receives `HTTP/2 400` after the switch to *Blocking*. Its `x-azion-request-id` finds the record in Real-Time Events. These checks confirm the [Block account takeover on login and checkout flows](/en/documentation/use-cases/secure-applications-and-networks/block-account-takeover-on-login-and-checkout-flows/) use case. In the [Prepare regulated web applications for security audits](/en/documentation/use-cases/secure-applications-and-networks/prepare-regulated-web-applications-for-security-audits/) use case, expect: - **Attack patterns are filtered.** Send `https://www.example.com/?q=1%27%20OR%20%271%27%3D%271`. With the WAF rule in *Blocking*, the response is `400`. --- ## Next steps - [Switch a rule set to blocking](/en/documentation/guides/application-security/firewall-and-waf/switch-to-blocking.md): Change the mode on this behavior after the rule is already in place. - [Scoring and modes](/en/documentation/platform/firewall/waf/scoring-and-modes.md): Where this rule sits in the path a request travels, and what happens after it matches. - [Protect web applications from OWASP Top 10 and zero-day attacks](/en/documentation/use-cases/secure-applications-and-networks/protect-web-applications-from-owasp-top-10-and-zero-day-attacks.md): A web application whose firewall runs network lists, WAF, and Bot Manager in one policy. - [Protect public APIs from abuse](/en/documentation/use-cases/secure-applications-and-networks/protect-public-apis-from-abuse.md): An API whose rate limit runs last, after WAF, a token check, and Bot Manager. - [Block account takeover on login and checkout flows](/en/documentation/use-cases/secure-applications-and-networks/block-account-takeover-on-login-and-checkout-flows.md): Login, signup, and checkout scored for automation, then challenged or denied. - [Prepare regulated web applications for security audits](/en/documentation/use-cases/secure-applications-and-networks/prepare-regulated-web-applications-for-security-audits.md): An audit setup that exports every request and WAF event to a destination the team keeps.