Azure App Gateway WAF_v2 Custom Rule evaluation of RequestUri fails to limit allowed paths

Question

Azure App Gateway WAF_v2 Custom Rule evaluation of RequestUri fails to limit allowed paths

Marius Shekow 25

I have an Azure App Gateway (AppGW) whose public listener I configured with a Path-based routing rule. That Routing Rule has a default backend configured (which is required, even though I would prefer not to), and several routes, e.g.

Path "/a/*" sends traffic to backend pool A
Path "/b/*" sends traffic to backend pool B

What I would like to implement is that AppGW denies incoming HTTP calls (with status code 403) made to any paths other than "/a/" or "/b/" (e.g. calls made to "/foo").

I thought that I could use a WAF policy for this, but this does not seem to be possible.

What I've tried, but it does not do what I want:

I created a WAF Policy with a custom rule:

it is a "Match" type rule for a String
the Match variable is set to RequestUri
the "is not" operator is enabled
the Operator is set to "Begins with"
For the Match Values, I provide the list of paths, e.g. "/a/" and "/b/"
Action is "Deny traffic"

However, the problem is that the WAF engine has a weird behavior when evaluating the custom rule: For instance, if I make an HTTP call to "/a/xyz" (which should not be blocked), instead of matching the original (full) request URI, the WAF engine only evaluates "/xyz" (according to the AGWFirewallLogs LAW table entries), and then blocks the request. So, it seems that only the Uri part that "remains" within the specific Path rule is evaluated.

For now, my workaround is to configure the Path-based routing rule with a default backend that is actually empty, so AppGW responds to calls made to "/foo" with 502, but I would have preferred to do this via a WAF policy.

Any ideas on how this could be improved?

G Sree Vidya 4,005 Reputation points Microsoft External Staff Moderator

2025-07-16T22:15:10.4933333+00:00
Hi Marius Shekow

You want to deny any requests that don’t match "/a/" or "/b/" and are looking for a way to achieve that through WAF policies, but it seems the WAF is not processing the full URI as you intended.

Your approach of setting a custom rule to deny traffic based on conditions related to the RequestUri is indeed valid, but it looks like the WAF is only evaluating the tail end of your paths due to the path-based routing you've set up.

Here are a couple of suggestions to improve your configuration:

1.Use a Catch-All Path Rule:

Add a path rule like /* at the end of your path-based routing rules.

Route it to a backend pool that returns a 403 or a custom error page.

This ensures that any unmatched path is explicitly handled.

Go to your Application Gateway > Rules > Select your path-based routing rule.

Associate the WAF policy to the listener or globally (not per-path).

Ensure the default backend pool is valid (e.g., a dummy backend that returns 403, or rely on WAF to block).

refer:https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/custom-waf-rules-overview

Use Azure Front Door Instead

Azure Front Door (AFD) offers more granular control over routing and WAF evaluation.

You can define global WAF policies and route-based rules with better URI visibility.

AFD also supports geo-filtering and rate limiting more natively

Log and Monitor with Azure Monitor

Use Azure Monitor and AGWFirewallLogs to track which paths are being accessed.

This can help you fine-tune your WAF rules or identify patterns for additional blocking.

I hope this helps! If these answers your query, do click the "Upvote" and click "Accept the answer" of which might be beneficial to other community members reading this thread.

If the above is unclear or you are unsure about something, please add a comment below.
Marius Shekow 25 Reputation points

2025-07-17T08:11:54.7133333+00:00

Hello @G Sree Vidya , thanks for your response.

While your suggestion would technically work, it would require me to set up such a dedicated server just to serve 403 responses. I want to avoid that, because it costs money, and also such a server might be vulnerable to hacking attacks.

Instead, I would prefer have AppGW or its WAF to block requests (made to paths other than /a/.. or /b/...) directly. It seems that this is not possible and I'll need to stick to my workaround with defining an empty backend pool, which serves 502 HTTP status responses (instead of 403), but that is not a "huge" issue. Unless there is someone else who can offer a solution.

While I'm sure that Azure Front Door is more capable and suited to solve my question, we are not planning to use that product. It's too expensive.
G Sree Vidya 4,005 Reputation points Microsoft External Staff Moderator

2025-07-17T22:30:26.3066667+00:00
Hello Marius Shekow

Thank you for the clarification, and I completely understand your concern about avoiding the cost and potential exposure of maintaining a dedicated backend just to return 403 responses.

You're right. Azure Application Gateway WAF currently does not support directly denying requests based on unmatched paths (e.g., anything not starting with /a/ or /b/) without routing them to a backend. The WAF custom rules are evaluated after routing decisions, which limits their ability to act as a gatekeeper for unmatched paths.

You can use the method of assigning unmatched paths to an empty backend pool in Azure Application Gateway (AppGW) to effectively block requests that don’t match /a/ or /b/.

While this results in a 502 Bad Gateway instead of a 403 Forbidden, it:

Does not require a dedicated backend server, which saves cost and reduces attack surface.

Effectively blocks access to unwanted paths.

Is a commonly accepted workaround given the current limitations of AppGW and WAF.

Do let me know if you have questions.
Marius Shekow 25 Reputation points

2025-07-21T08:20:19.04+00:00
I found a solution:

In the URL Path map, create a fallback path rule (placed last) for /* and make sure to assign a valid (non-empty) backend pool, e.g., use the same one that I also use for /a/*

Create a WAF policy and associate it with that just-created fallback path rule, and configure a Custom Rule that matches the RequestUri via Regex .*, denying all traffic.

Accepted answer

0 additional answers

Your answer

G Sree Vidya 4,005 Reputation points Microsoft External Staff Moderator

2025-07-16T22:15:10.4933333+00:00

Hi Marius Shekow

You want to deny any requests that don’t match "/a/" or "/b/" and are looking for a way to achieve that through WAF policies, but it seems the WAF is not processing the full URI as you intended.

Your approach of setting a custom rule to deny traffic based on conditions related to the RequestUri is indeed valid, but it looks like the WAF is only evaluating the tail end of your paths due to the path-based routing you've set up.

Here are a couple of suggestions to improve your configuration:

1.Use a Catch-All Path Rule:

Add a path rule like /* at the end of your path-based routing rules.

Route it to a backend pool that returns a 403 or a custom error page.

This ensures that any unmatched path is explicitly handled.

Go to your Application Gateway > Rules > Select your path-based routing rule.

Associate the WAF policy to the listener or globally (not per-path).

Ensure the default backend pool is valid (e.g., a dummy backend that returns 403, or rely on WAF to block).

refer:https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/custom-waf-rules-overview

Use Azure Front Door Instead

Azure Front Door (AFD) offers more granular control over routing and WAF evaluation.

You can define global WAF policies and route-based rules with better URI visibility.

AFD also supports geo-filtering and rate limiting more natively

Log and Monitor with Azure Monitor

Use Azure Monitor and AGWFirewallLogs to track which paths are being accessed.

This can help you fine-tune your WAF rules or identify patterns for additional blocking.

I hope this helps! If these answers your query, do click the "Upvote" and click "Accept the answer" of which might be beneficial to other community members reading this thread.

If the above is unclear or you are unsure about something, please add a comment below.
Marius Shekow 25 Reputation points

2025-07-17T08:11:54.7133333+00:00

Hello @G Sree Vidya , thanks for your response.

While your suggestion would technically work, it would require me to set up such a dedicated server just to serve 403 responses. I want to avoid that, because it costs money, and also such a server might be vulnerable to hacking attacks.

Instead, I would prefer have AppGW or its WAF to block requests (made to paths other than /a/.. or /b/...) directly. It seems that this is not possible and I'll need to stick to my workaround with defining an empty backend pool, which serves 502 HTTP status responses (instead of 403), but that is not a "huge" issue. Unless there is someone else who can offer a solution.

While I'm sure that Azure Front Door is more capable and suited to solve my question, we are not planning to use that product. It's too expensive.
G Sree Vidya 4,005 Reputation points Microsoft External Staff Moderator

2025-07-17T22:30:26.3066667+00:00

Hello Marius Shekow

Thank you for the clarification, and I completely understand your concern about avoiding the cost and potential exposure of maintaining a dedicated backend just to return 403 responses.

You're right. Azure Application Gateway WAF currently does not support directly denying requests based on unmatched paths (e.g., anything not starting with /a/ or /b/) without routing them to a backend. The WAF custom rules are evaluated after routing decisions, which limits their ability to act as a gatekeeper for unmatched paths.

You can use the method of assigning unmatched paths to an empty backend pool in Azure Application Gateway (AppGW) to effectively block requests that don’t match /a/ or /b/.

While this results in a 502 Bad Gateway instead of a 403 Forbidden, it:

Does not require a dedicated backend server, which saves cost and reduces attack surface.

Effectively blocks access to unwanted paths.

Is a commonly accepted workaround given the current limitations of AppGW and WAF.

Do let me know if you have questions.
Marius Shekow 25 Reputation points

2025-07-21T08:20:19.04+00:00

I found a solution:

In the URL Path map, create a fallback path rule (placed last) for /* and make sure to assign a valid (non-empty) backend pool, e.g., use the same one that I also use for /a/*

Create a WAF policy and associate it with that just-created fallback path rule, and configure a Custom Rule that matches the RequestUri via Regex .*, denying all traffic.

Answer 1

Hello Marius Shekow

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others", I'll repost your solution.

Issue: Azure App Gateway WAF_v2 Custom Rule evaluation of RequestUri fails to limit allowed paths

Solution:

In the URL Path map, create a fallback path rule (placed last) for /* and make sure to assign a valid (non-empty) backend pool, e.g., use the same one that I also use for /a/*
Create a WAF policy and associate it with that just-created fallback path rule, and configure a Custom Rule that matches the RequestUri via Regex .*, denying all traffic.

Please click "Accept" the answer as original posters help the community find answers faster by identifying the correct answer.

Share via

Azure App Gateway WAF_v2 Custom Rule evaluation of RequestUri fails to limit allowed paths

0 additional answers

Your answer