Web Application Firewall

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. 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 with the Set WAF Rule Set behavior or via Azion API.

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

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.

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.

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.

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.

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
• RFC 2388 – Returning Values from Forms: multipart/form-data

You can find the detailed description of Rule 13 and its parameters on the WAF Rule Sets 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.

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.

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.

Allowed Rules

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

The Allowed Rules are composed of the fields:

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.

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 and the Azion API reference.

Limits

These are the default limits: