Azure Application Gateway: Implementing Path-Based WAF Policies

If you’ve ever put a Web Application Firewall (WAF) in front of a dynamic website or a Content Management System (like WordPress, Drupal, or a custom portal), you’ve probably experienced the immediate, frustrating reality of "false positives."

You lock down your website to stop hackers, but suddenly, your own content editors can’t save their work. They get "403 Forbidden" errors just for uploading an image or writing a paragraph with HTML tags.

Let's be candid: a WAF is a highly effective, but very blunt instrument. To a WAF, a content creator pasting a long, formatted paragraph into a text box looks exactly like a hacker trying to inject a malicious Cross-Site Scripting (XSS) or SQL Injection (SQLi) payload.

The worst thing you can do is globally turn off those security rules just so your team can work. Doing so leaves your public-facing site completely vulnerable.

The correct solution? Path-Based WAF Policies.

Here is the ultimate beginner's guide to architecting a secure, dual-policy WAF in Azure Application Gateway.

The Concept: Two Rulebooks, One Gateway

Instead of applying one generic set of rules to your entire website, we are going to create two separate security zones:

1. The Global Policy (Strict): This is your frontline defender. It inspects all public traffic (/) with zero exceptions. If a visitor tries to submit SQL code into your public search bar or contact form, they are blocked immediately.
2. The Admin Policy (Lenient): This is a custom rulebook applied only to your backend administration URLs (like /admin/* or /wp-admin/*). It leaves all the main security rules turned on, but includes highly specific exclusions to allow your staff to submit complex data without triggering false alarms.

By using Path-Based Routing, the Application Gateway seamlessly switches the rulebook based on the URL the user is visiting.

Step-by-Step Configuration Guide

Step 1: Secure the Front Door (The Global Policy)

First, you need a strict policy for your public traffic.

1. Navigate to Web Application Firewall policies (WAF) in Azure and create a new policy (e.g., WAF-Policy-Global).
2. Set the state to Prevention mode.
3. Ensure your Managed Rule Sets (like OWASP 3.2) are fully enabled.
4. Crucial: Do not add exclusions for HTML content or large data arrays here. You want this policy to catch everything.
5. Bind this policy to your Application Gateway globally, or to your specific public-facing Listener.

Step 2: Create the "Lenient" Admin Policy

Next, we create the specialized rulebook for your staff.

1. Create a second WAF Policy (e.g., WAF-Policy-Backend).
2. Configure it with the same base settings (Prevention mode, OWASP rules enabled).
3. Go to the Managed rules -> Exclusions section.

This is where you tell the WAF to create tiny, deliberate blind spots for your administrative tools. Instead of turning off a rule entirely, you tell the WAF to stop inspecting specific data fields that you know are safe.

Example Exclusions:

• Scenario: Your CMS uses a field called article_body to save HTML text.
  • Exclusion: Match Variable: RequestArgNames | Operator: Equals | Selector: article_body | Rules to Exclude: 941320 (XSS), 942430 (SQLi).
• Scenario: Your system uses a cookie called admin_session_token that triggers false alarms due to special characters.
  • Exclusion: Match Variable: RequestCookieNames | Operator: Starts with | Selector: admin_session_ | Rules to Exclude: 942100 (SQLi).

Step 3: Map the Paths in Application Gateway

Now we have to tell the Application Gateway how to separate the traffic so we can apply our new policy.

1. Open your Application Gateway resource and navigate to Routing rules (under Settings).
2. Click on your existing routing rule to edit it.
3. Go to the Backend targets tab.
4. Under the Path-based routing section, click Add multiple targets to create a path-based rule.
5. Create a new path target:
   • Name: Admin-Paths
   • Paths: /admin/* (or whatever your backend path is).
   • Target Type: Backend pool
   • Select your existing backend pool and HTTP settings.
6. Click Add and Save the rule.

Note: Your public traffic (/*) will continue to use the default target at the top of the routing rule menu.

Step 4: Bind the Admin Policy to the Admin Path

The final step is linking your lenient policy to the specific hallway you just created.

1. Go back to your lenient WAF Policy (WAF-Policy-Backend).
2. On the left menu, click Associated resources.
3. Click + Add association and choose HTTP Path from the dropdown.
4. Select your Application Gateway and the Routing Rule you just edited.
5. Check the box next to your new /admin/* path and click Add.

Security Reality Check

Path-based routing solves the operational nightmare of false positives, but it comes with a massive caveat: You have deliberately created a blind spot on your backend. Because the WAF is no longer inspecting specific fields on your /admin/ path for malicious code, you must enforce strict access controls.

• Enforce MFA: If an attacker steals an admin's password, the WAF will not stop them from logging in and exploiting those excluded fields. Multi-Factor Authentication is non-negotiable.
• Restrict IP Access: If possible, use Network Security Groups (NSGs) or Azure Front Door features to restrict access to your /admin/ paths so they can only be reached from your corporate VPN or trusted office IPs.

By separating your WAF policies based on the user's path, you achieve the holy grail of web hosting: maximum security for your visitors, and frictionless operation for your team.