Azure Application Gateway: Implementing an Implicit Deny Rule in WAF Policies

Azure Application Gateway: Implementing an Implicit Deny Rule in WAF Policies


For an actual home lab project, I needed a well-known firewall resource, the Implicit Deny Rule, which is typically given in any firewall nowadays. Implementing this rule in an Azure Application Gateway can be tricky as I haven’t found much information about it on the internet. In my blog, I will briefly outline what an implicit deny rule is and further give instructions on creating a custom rule in a Web Application Firewall (WAF) policy within the Azure Application Gateway.

1. What is an Implicit Deny Rule?

An Implicit Deny Rule is a single rule of a firewall rule set that is mostly the last rule baked in or created by someone at the end of the rule set and automatically blocks any incoming request that doesn’t fit in the set of firewall rules you’ve configured before. It’s like a bouncer at a club – unless you’re on the list, you’re not getting in. Because the Implicit Deny Rule is the last in a rule set, it will match when every other rule before is evaluated and doesn’t match.

2. An Implicit Deny Rule in the Azure Application Gateway environment

In Azure Application Gateways, Implicit Deny Rules could be used in the Custom rules of an Azure Application Gateway WAF policy to control access to the exposed web resources or services behind the Azure Application Gateway. By creating a set of Custom rules, you can decide who can and can’t access your published web resources or services. When a web request gets in, it can be rewritten by a rewriting rule, and only then will it be checked against these Web Application Firewall rules (That’s important!). If it fits the rules, it’s allowed through. If it doesn’t, it should be blocked by the Implicit Deny Rule. Via the “Application Gateway WAF Custom Policies”, you can block and allow access by, e.g., IP Addresses, Geo Locations, or by a String like the RequestURI or RequestHeader. More about these Attributes can be found here

3. Why do I need an Implicit Deny Rule in the Azure Application Gateway WAF Policies?

In my case, I wanted to publish various of my web services on the Internet through an Azure Application Gateway. Still, these should only be accessible from a group of specific IP addresses on certain paths. After creating the appropriate rules for allowed access, anyone could still access the resources; there was no blocking component. So I needed a deny rule to restrict access so that no one except the allowed IP-Ranges can access the resources.

4. Creating a Custom rule with an Implicit Deny Rule

For creating Custom rules on an Azure Application Gateway, you need at first the SKU WAFv2 enabled at the Application Gateway. Further, the WAF should be enabled, and the mode should be set to “Prevention”, otherwise, the WAF just logs the denied Access but doesn’t actually block them.

I presume you already created a Web Application Firewall policy; otherwise, you can search for it in the Azure Marketplace and create the resource.

When the custom WAF Policy is created, you can navigate to the Custom rules section in the Web Application Firewall policies (WAF) Resource.

As you can see in the screenshots, I created two rules, the “AllowAccess” rule and, more important, the “DenyAccess” rule, which functions as the Implicit Deny Rule.

Here is a detailed view of the Implicit Deny Rule Setting.

When I now navigate to paths like “/pictures/”, “/documents/” and “/data/” on my development domain via web browser, the access is possible for the Paths & with my fictive IP-Address of The AllowAccess Rule matches correctly.

Now when I navigate to the domain (root path) or the “/secretinformations/” path of the website, the access is restricted as it should be due to the Implicit Deny Rule.

5. Conclusion

Currently, this is the best option I know to create an Implicit Deny Rule for the Azure Application Gateway and the Web Application Firewall. It can be further optimized, and I bet there are alternate solutions. In my case, this Custom rule works and protects the web services and paths against unwanted access.