# Web Application Firewall

import DocButton from '~/components/webkit/DocButton.vue';


**Web Application Firewall (WAF)** is an Azion **Firewall** module, developed to protect applications from threats such as *SQL Injections*, *Remote File Inclusion (RFI)*, *Cross-Site Scripting (XSS)*, *Cross-Site Request Forgery (CSRF)*, *protocol violations* (such as empty body in POST), *Code Injection*, and other web vulnerabilities, including the [most common cyberthreats](https://www.azion.com/en/learning/websec/how-does-waf-protect-against-cyberthreats/#what-are-the-most-common-cyberthreats). WAF analyzes HTTP and HTTPS requests, detects, and blocks malicious activity before it reaches your application infrastructure.

WAF operates in the seventh layer of the OSI model, the application layer, where the relationship between web applications and their respective network services and user data takes place. It also works as a barrier to filter and monitor traffic between your application and the requests from the internet.

**Web Application Firewall** is based on requests *scoring* methodology. Each HTTP/HTTPS request is compared to a very strict and detailed set of application standards and given a *score* that is associated with a particular family of threats. According to the *score* received by the request, it can be released or blocked directly in Azion's edge nodes, before the threat reaches its origin or causes any type of damage. You define the desired level of sensitivity for blocking each family of threats.

WAF can operate in two modes: **Learning** or **Blocking**. You can set the mode in a rule in [Rules Engine](/en/documentation/products/secure/firewall/rules-engine/) with the **Set WAF Rule Set** behavior or via [Azion API](https://api.azion.com/#ace1b2f6-253a-48a1-bf58-4c5381e22c21).

You can use the **Learning** mode to avoid blocking lawful requests and malfunctions of your application. In this step, WAF identifies the legitimate behaviors of your application by placing them in an *allowlist*.

If internal traffic, tests, and false positives are being blocked by WAF, you can also fine-tune its settings in the **Tuning** feature, available inside a WAF configuration.

### POST requests and supported content types

When analyzing `POST` requests, WAF only parses the request body when the `Content-Type` header uses one of the following types:

- `application/x-www-form-urlencoded`
- `multipart/form-data`
- `application/json`
- `application/vnd.api+json`
- `application/csp-report`

When the `Content-Type` isn’t one of the supported types, the request body may be considered non‑parsable by WAF. This affects how some protocol validation rules are applied, including rules related to validating the `POST` format.

## Implementation

| Scope | Source |
| ----- | ------ |
| Create WAF rule set | [How to create a WAF rule set](/en/documentation/products/guides/secure/create-waf-rule-set/) |
| WAF mode | [How to check your WAF mode](/en/documentation/products/guides/how-to-check-your-waf-mode/) |
| WAF score | [How to find information about WAF blocked requests](/en/documentation/products/guides/how-to-find-waf-score/) |
| Integrate WAF with SIEMs | [How to integrate WAF with SIEMs](/en/documentation/products/secure/automate/integrate-siems/) |

## Prerequisites

To configure a **WAF Rule Set**, which is what a WAF configuration is called, you must have an Firewall configuration with the Web Application Firewall module activated.

:::tip
Learn more about [Firewall modules](/en/documentation/products/secure/firewall/) and the [Rules Engine for Firewall](/en/documentation/products/secure/firewall/rules-engine/).
:::


<DocButton href="/en/documentation/products/guides/secure/firewall-configure-main-settings/" label="go to configure firewall guide" kind="secondary" size="medium" /> 

## WAF Main Settings

The **Main Settings** section is configured by activating protection against specific threat families: SQL Injection, Remote File Inclusions (RFI), Directory Traversal, Cross-Site Scripting (XSS), File upload, Evading tricks, Unwanted Access, and Identified Attack, and setting a sensitivity level: Lowest, Low, Medium, High, and Highest.

The **Threat Type Configuration** table categorizes threats into families, according to the purpose of the attack.

<DocButton href="/en/documentation/products/secure/firewall/web-application-firewall/rules-set/#threat-types" label="go to types of threats reference" kind="secondary" size="medium" /> <br></br>

<DocButton href="/en/documentation/products/guides/secure/create-waf-rule-set/" label="go to create a rule set guide" kind="secondary" size="medium" />

It's possible to enable and disable protection for each threat family individually through the **Active** switch.

**Sensitivity** levels define how strictly WAF will consider a request as a threat. 

Each sensitivity level tolerates a defined number of threat indicatives and the WAF score represents this amount of threat indicatives. The more flexible the sensitivity level is, the higher the WAF score it accepts. The most rigid sensitivity levels, on the other hand, only accept requests with fewer signs of threats.

<DocButton href="/en/documentation/products/secure/firewall/web-application-firewall/rules-set/#sensitivity-levels" label="go to sensitivity levels reference" kind="secondary" size="medium" />

## WAF Rule IDs

Each WAF rule has a unique numeric identifier, called `Rule ID`. 

- **Visibility:** the `Rule IDs` appear on the **WAF Tuning** and **Allowed Rules** screens.
- **Usage:** you can use the `Rule ID` to identify, filter, and allow/block specific behaviors of your application.
- **Full list:** see the description of rule families and their `Rule IDs` in [WAF Rule Sets](/en/documentation/products/secure/firewall/web-application-firewall/rules-set/).

### Rule 13: POST format validation

**Rule 13** in WAF is related to validating the format of `POST` requests, ensuring that the request body complies with the message formats defined by HTTP standards.

It considers, among other factors:

- The HTTP method used (`POST`).
- The configured `Content-Type`.
- How the body is serialized (for example, `application/x-www-form-urlencoded`, `multipart/form-data`, `application/json`).

To understand the expected formats and the semantics of `POST` requests, see:

- [RFC 7231 – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](https://datatracker.ietf.org/doc/html/rfc7231)
- [RFC 2388 – Returning Values from Forms: multipart/form-data](https://datatracker.ietf.org/doc/html/rfc2388)

You can find the detailed description of Rule 13 and its parameters on the [WAF Rule Sets](/en/documentation/products/secure/firewall/web-application-firewall/rules-set/) page.

## WAF Tuning

**WAF Tuning** is an analytical tool that shows requests detected for each WAF rule. All matches are displayed grouped by **rule ID**, along with additional information to help in the identification, such as **total hits, number of URIs, unique IPs**, and more to help setup the **Allowed Rules** for the given WAF to match best calibration for your application. You can filter by **Domain**, **Time Range**, **Network Lists**, **IP**, and **Countries**.

<DocButton href="/en/documentation/products/guides/secure/tune-waf/" label="go to tune WAF guide" kind="secondary" size="medium" /> 

When selecting a listed Rule shown in the results, you can drill down into the **More Details** screen to view related occurrences for the given Rule ID. This enables you to understand and pinpoint the exact cases that should be added to the **Allowed Rules**, supported by filtering options such as **Network List, Country, IP**, and **Path**.

In the filters below, you can enter the **Domain** (required), **Time Range**, which **Network Lists** you prefer to use, which **IPs** you are investigating, and the **Country** of origin of the requests.

:::note
To see requests identified by WAF, you must at least specify the domain (or the domains) of your application.
:::

By clicking the **Apply filter** button, a list of **Possible Attacks** will be displayed. This list includes the fields **Rule ID**, **Description**, **Hits**, **IPs**, **Countries**, **Top 10 IPs Address**, and **Top 10 Countries**. Now you can select the ones you need and click **Allow Rules** to add them to the Allowed Rules of this WAF.
<DocButton href="/en/documentation/products/secure/firewall/web-application-firewall/custom-allowed-rules/" label="go to WAF Custom Allowed Rules reference" kind="secondary" size="medium" />

## Allowed Rules

This tab allows you to create, edit, and delete *Allowed Rules* (also referred to as **Exceptions** in the API).

:::note
**Exceptions** is the terminology used in the Azion API. In the Console interface, you'll see **Allowed Rules**. Both terms refer to the same functionality.
:::

The Allowed Rules are composed of the fields:

| Field | Description |
| ----- | ----------- |
| `Rule ID` | Unique numeric ID of a WAF Rule. See the list of rules in [WAF Rule Sets](/en/documentation/products/secure/firewall/web-application-firewall/rules-set/). |
| `Rule Description` | Automatic textual description of what the rule is/does |
| `Reason` | Alternative manual textual description |
| `URI` | *Uniform Resource Identifier (URI)* is the path that goes after the domain in the URL |
| `Path` | When specified, restricts the application of the `Match Zone` only to the defined path. The path delimits the scope of action of the rule | 
| `Match Zone` | Parts or fields of the requisition that'll be compared with the `match pattern`. Read more about each option in the [Match Zones table](#match-zone-dropdown-options) below | 
| `Active` | Allowed Rule active status switch |

### Match Zone dropdown options

The **Match Zone** dropdown opens the options available to complete this field. Each option has a specific behavior, as explained in the table below.

:::note
Options starting with **Specific** require you to provide a value in the **Name** field to specify which element you want to compare.
:::

| Field | Description | Usage Example |
| ----- | ---------- | ------------- |
| `Any HTTP Header Value` | `Match pattern` will be compared with the value of any HTTP header in the request | Compares with values like `Mozilla/5.0`, `application/json`, etc. |
| `Any HTTP Header Name` | `Match pattern` will be compared with the name of any HTTP header in the request | Compares with names like `User-Agent`, `Content-Type`, `Authorization`, etc. |
| `Specific HTTP Header Value` | `Match pattern` will be compared with the value of a specific HTTP header in the request | Name: `User-Agent` — compares only the User-Agent header value |
| `Specific HTTP Header Name` | `Match pattern` will be compared with the name of a specific HTTP header in the request | Name: `X-Custom-Header` — checks if a header with this name exists |
| `Any Query String Value` | `Match pattern` will be compared with the value of any query string parameter | In `?id=123&user=admin`, compares with `123` and `admin` |
| `Any Query String Name` | `Match pattern` will be compared with the name of any query string parameter | In `?id=123&user=admin`, compares with `id` and `user` |
| `Specific Query String Value` | `Match pattern` will be compared with the value of a specific query string parameter | Name: `session_id` — compares only the `session_id` parameter value |
| `Specific Query String Name` | `Match pattern` will be compared with the name of a specific query string parameter | Name: `token` — checks if a parameter named `token` exists |
| `Body Form Field Value` | `Match pattern` will be compared with the value of any form field in the request body | Compares values of fields like `username`, `password`, etc. |
| `Body Form Field Name` | `Match pattern` will be compared with the name of any form field in the request body | Compares form field names |
| `Specific Body Form Field Value` | `Match pattern` will be compared with the value of a specific form field in the request body | Name: `password` — compares only the `password` field value |
| `Specific Body Form Field Name` | `Match pattern` will be compared with the name of a specific form field in the request body | Name: `api_key` — checks if a field with this name exists |
| `Any URL` | `Match pattern` will be compared with any part of the request URL | Compares with the full URL or parts of it |
| `Raw Body` | `Match pattern` will be compared to the uninterpreted body of a request, also called the *unparsed body* | Useful for analyzing raw JSON or XML payloads |
| `File Extension` | `Match pattern` will be compared with the file extension in the request | Compares extensions like `.php`, `.exe`, `.sh` |

:::note
The `Last Editor` and `Last Modified` fields are only available through the [API](https://api.azion.com).
:::

### Managing Exceptions via API

You can manage Allowed Rules (Exceptions) programmatically using the Azion API. This enables you to:

- Automate exception creation based on WAF Tuning analysis
- Integrate WAF calibration into CI/CD pipelines
- Build custom tools for managing security configurations
- Bulk update or deactivate exceptions across multiple WAF Rule Sets

For complete API specifications and examples, see the [WAF Exceptions documentation](/en/documentation/products/secure/firewall/web-application-firewall/custom-allowed-rules/#managing-exceptions-via-api) and the [Azion API reference](https://api.azion.com/v4#/operations/list_waf_exceptions).

---

## Limits

:::tip
**Increase limits** <br></br>
You can request to increase the limits based on your plan. Contact the [technical support team](/en/documentation/services/support/) to request it.
:::

These are the **default limits**:

| Scope | Limit |
| ----- | ----- |
| Debug Rules log size | 1.5 kB |
| WAF Tuning queries | 3 days |
| Request maximum payload size | 160 KB |

:::note
**Request Payload Size Limit**  
Payloads larger than 160KB will not be parsed by WAF and will trigger the rule 2 of WAF.
:::