Frequently asked questions for Azure Web Application Firewall on Azure Front Door

Azure Web Application Firewall is a web application firewall (WAF) that helps protect your web applications from common threats such as SQL injection, cross-site scripting, and other web exploits. You can define a WAF policy that consists of a combination of custom and managed rules to control access to your web applications.

You can apply a WAF policy to web applications hosted on Azure Application Gateway or Azure Front Door.

Azure Front Door is an application and content delivery network that's highly scalable and globally distributed. Azure Web Application Firewall, when it's integrated with Azure Front Door, stops denial-of-service and targeted application attacks at the Azure network edge (close to attack sources) before they enter your virtual network. This combination offers protection without sacrificing performance.

Azure Front Door offers Transport Layer Security (TLS) offloading. Azure Web Application Firewall is natively integrated with Azure Front Door and can inspect a request after it's decrypted.

Yes. You can configure IP restriction for IPv4 and IPv6. For more information, see the blog post on IPv6 adoption for enhancing Azure Web Application Firewall on Azure Front Door.

We do our best to keep up with changing threat landscape. When we update a rule, we add it to the Default Rule Set (DRS) with a new version number.

Most WAF policy deployments finish in less than 20 minutes. You can expect the policy to take effect as soon as the update is completed across all edge locations globally.

When Azure Web Application Firewall is integrated with Azure Front Door, the WAF is a global resource. The same configuration applies across all Azure Front Door locations.

You can configure an IP access control list in your back end to allow for only Azure Front Door outbound IP address ranges by using an Azure Front Door service tag and deny any direct access from the internet. Service tags are supported for your virtual network. Additionally, you can verify that the X-Forwarded-Host HTTP header field is valid for your web application.

There are two options for applying WAF policies in Azure. Azure Web Application Firewall on Azure Front Door is a globally distributed, edge security solution. Azure Web Application Firewall on Application Gateway is a regional, dedicated solution. We recommend that you choose a solution based on your overall performance and security requirements. For more information, see Load balancing options.

When you enable the WAF on an existing application, it's common to have false-positive detections in which the WAF rules detect legitimate traffic as a threat. To minimize the risk of an impact to your users, we recommend the following process:

1. Enable the WAF in detection mode to ensure that the WAF doesn't block requests while you're working through this process. We recommend this step for testing purposes on the WAF.

   Important

   This process describes how to enable the WAF on a new or existing solution when your priority is to minimize the disturbance to your application's users. If you're under attack or imminent threat, you might want to instead deploy the WAF in prevention mode immediately. You can then use the tuning process to monitor and tune the WAF over time. This approach will probably cause some of your legitimate traffic to be blocked, which is why we recommend using it only when you're under threat.

2. Follow the guidance for tuning the WAF. This process requires that you enable diagnostic logging, review the logs regularly, and add rule exclusions and other mitigations.

3. Repeat this whole process and check the logs regularly, until you're satisfied that no legitimate traffic is being blocked. The whole process might take several weeks. Ideally, you should see fewer false-positive detections after each tuning change that you make.

4. Finally, enable the WAF in prevention mode.

Even after you're running the WAF in production, you should keep monitoring the logs to identify any other false-positive detections. Regularly reviewing the logs also helps you identify any real attack attempts that were blocked.

Currently, Core Rule Set (CRS) 3.0, CRS 3.1, and CRS 3.2 rules are supported only with Azure Web Application Firewall on Application Gateway. Rate limiting and Azure-managed DRS rules are supported only with Azure Web Application Firewall on Azure Front Door.

Azure Front Door is globally distributed at Azure network edges. It can absorb and geographically isolate large-volume attacks. You can create a custom WAF policy to automatically block and rate limit HTTP and HTTPS attacks that have known signatures. You can also enable distributed denial-of-service (DDoS) network protection on the virtual network where your back ends are deployed.

Customers of the Azure DDoS Protection service receive additional benefits, including cost protection, a service-level agreement (SLA) guarantee, and access to experts from the DDoS Rapid Response Team for immediate help during an attack. For more information, see DDoS Protection on Azure Front Door.

You might not see requests immediately blocked by the rate limit when different Azure Front Door servers process requests. For more information, see Rate limits and Azure Front Door servers.

The Azure Front Door WAF supports the following content types:

• DRS 2.0

  Managed rules:

  • application/json
  • application/xml
  • application/x-www-form-urlencoded
  • multipart/form-data

  Custom rules:

  • application/x-www-form-urlencoded

• DRS 1.x

  Managed rules:

  • application/x-www-form-urlencoded
  • text/plain

  Custom rules:

  • application/x-www-form-urlencoded

No, you can't. The Azure Front Door profile and the WAF policy need to be in the same subscription.

Related content

• What is Azure Web Application Firewall?
• What is Azure Front Door?