Web Application Firewall with Azure Front Door exclusion lists
Sometimes Azure Web Application Firewall in Azure Front Door might block a legitimate request. As part of tuning your web application firewall (WAF), you can configure the WAF to allow the request for your application. WAF exclusion lists allow you to omit specific request attributes from a WAF evaluation. The rest of the request is evaluated as normal.
For example, Microsoft Entra ID provides tokens that are used for authentication. When these tokens are used in a request header, they can contain special characters that might trigger a false positive detection by one or more WAF rules. You can add the header to an exclusion list, which tells the WAF to ignore the header. The WAF still inspects the rest of the request for suspicious content.
You can create exclusions at the following scopes:
- Rule set: These exclusions apply to all rules within a rule set.
- Rule group: These exclusions apply to all the rules of a particular category within a rule set. For example, you can configure an exclusion that applies to all the SQL injection rules.
- Rule: These exclusions apply to a single rule.
Exclusion selectors identify the parts of requests to which the exclusion applies. The WAF ignores any detections that it finds in the specified parts of the request. You can specify multiple exclusion selectors in a single exclusion.
Each exclusion selector specified a match variable, an operator, and a selector.
You can add the following request attributes to an exclusion:
- Request header name
- Request cookie name
- Query string args name
- Request body POST args name
- Request body JSON args name (supported on DRS 2.0 or greater)
The values of the fields you use aren't evaluated against WAF rules, but their names are evaluated. The exclusion lists disable inspection of the field's value. However, the field names are still evaluated. For more information, see Exclude other request attributes.
You can specify an exact request header, body, cookie, or query string attribute to match. Or you can optionally specify partial matches. The following operators are supported for match criteria:
- Equals: Match all request fields that exactly match the specified selector value. For example, to select a header named bearerToken, use the
Equalsoperator with the selector set to bearerToken.
- Starts with: Match all request fields that start with the specified selector value.
- Ends with: Match all request fields that end with the specified selector value.
- Contains: Match all request fields that contain the specified selector value.
- Equals any: Match all request fields. When you use the
Equals anyoperator, the selector value is automatically set to
*. For example, you can use the
Equals anyoperator to configure an exclusion that applies to all request headers.
Header and cookie names are case insensitive. Query strings, POST arguments, and JSON arguments are case sensitive.
Body contents inspection
Some of the managed rules evaluate the raw payload of the request body before it's parsed into POST arguments or JSON arguments. So in some situations, you might see log entries with a
matchVariableName value of
For example, suppose you create an exclusion with a match variable of
Request body POST args and a selector to identify and ignore POST arguments named
FOO. You no longer see any log entries with a
matchVariableName value of
PostParamValue:FOO. However, if a POST argument named
FOO contains text that triggers a rule, the log might show the detection in the initial body contents. You can't currently create exclusions for initial body contents.
Define exclusion rules based on Azure Web Application Firewall logs
You can use logs to view the details of a blocked request, including the parts of the request that triggered the rule. For more information, see Azure Web Application Firewall monitoring and logging.
Sometimes a specific WAF rule produces false positive detections from the values included in a request header, cookie, POST argument, query string argument, or JSON field in a request body. If these false positive detections happen, you can configure the rule to exclude the relevant part of the request from its evaluation.
The following table shows example values from WAF logs and the corresponding exclusion selectors that you could create.
|matchVariableName from WAF logs
|Rule exclusion in portal
|Request cookie name Equals SOME_NAME
|Request header name Equals SOME_NAME
|Request body POST args name Equals SOME_NAME
|Query string args name Equals SOME_NAME
|Request body JSON args name Equals SOME_NAME
Exclusions for JSON request bodies
From DRS version 2.0, JSON request bodies are inspected by the WAF. For example, consider this JSON request body:
The request includes a SQL comment character sequence, which the WAF detects as a potential SQL injection attack.
If you determine that the request is legitimate, you could create an exclusion with a match variable of
Request body JSON args name, an operator of
Equals, and a selector of
Exclude other request attributes
If your WAF log entry shows a
matchVariableName value that isn't in the preceding table, you can't create an exclusion. For example, you can't currently create exclusions for cookie names, header names, POST parameter names, or query parameter names.
Instead, consider taking one of the following actions:
- Disable the rules that give false positives.
- Create a custom rule that explicitly allows those requests. The requests bypass all WAF inspection.
In particular, when the
matchVariableName value is
QueryParamName, it means the name of the field, rather than its value, has triggered the rule. Rule exclusion has no support for these
matchVariableName values at this time.
- Configure exclusion lists on your Azure Front Door WAF.
- After you configure your WAF settings, learn how to view your WAF logs. For more information, see Azure Front Door diagnostics.