5.5 Web Application Firewall (WAF)
📘Microsoft Azure Networking Solutions (AZ-700)
A Web Application Firewall (WAF) is used to protect web applications from attacks such as SQL injection, cross-site scripting, and other web vulnerabilities. Once you create a WAF policy, the next step is to associate it with your application traffic so it can start protecting your resources.
1. What “Associating a WAF Policy” Means
When we say “associate a WAF policy”, it means:
- Connecting a WAF policy to an Azure resource that handles web traffic.
- This tells Azure where to enforce the rules in your WAF policy.
- Without association, your policy exists but does nothing.
You can associate a WAF policy with:
- Azure Front Door – A global service that handles web traffic and provides load balancing.
- Azure Application Gateway – A regional service that manages traffic within a specific Azure region.
2. Steps to Associate a WAF Policy
Let’s go step by step.
Step 1: Identify the Resource
- Choose the Azure service that needs protection:
- Application Gateway for regional apps.
- Front Door for global apps.
Step 2: Decide Scope
- Global WAF Policy (Front Door): Protects all routes or specific domains under Front Door.
- Regional WAF Policy (Application Gateway): Protects backend web apps behind the gateway.
Step 3: Associate the Policy
- In Azure Portal:
- Go to your WAF policy.
- Click “Associations”.
- Select the target resource (Front Door or App Gateway).
- Apply the policy.
- Using PowerShell / CLI:
Example for Application Gateway: Set-AzApplicationGateway -Name “MyAppGateway” -ResourceGroupName “MyResourceGroup” -WebApplicationFirewallPolicy $wafPolicy - Using ARM Templates: You can define the association in the template during deployment for automation.
3. Understanding the Association Behavior
When a WAF policy is associated:
- Policy Rules Apply – The rules in the policy start monitoring and/or blocking traffic.
- Mode Determines Action:
- Detection Mode – Logs potential threats but does not block them.
- Prevention Mode – Actively blocks threats based on rules.
- Custom Rules Take Effect – Any custom rules in your WAF policy (like blocking specific IPs or URLs) are enforced.
4. Key Exam Points to Remember
- A WAF policy must be associated with a resource to be active.
- One WAF policy can be associated with multiple resources, depending on type:
- Front Door supports multiple custom domains.
- App Gateway supports multiple listeners.
- Mode matters – Detection mode only logs, Prevention mode blocks attacks.
- Rule precedence:
- Custom rules take priority over managed rules.
- Managed rule sets provide baseline protection (like OWASP Core Rule Set).
5. IT Environment Example
Imagine you have a web application running in Azure:
- You deployed Application Gateway to manage traffic.
- You created a WAF policy with:
- Prevention mode ON.
- OWASP Core Rule Set enabled.
- A custom rule to block IPs from a specific region.
Now, to protect your application, you associate this WAF policy with the Application Gateway. From that moment:
- Any traffic hitting your application goes through WAF.
- The WAF checks the traffic against your policy.
- Threats are blocked before they reach your backend servers.
This ensures your web app stays secure without needing extra servers or software.
6. Quick Tips for the Exam
- Know which resources support WAF policies:
- Azure Front Door
- Application Gateway
- Remember the steps to associate (Portal, PowerShell, ARM Template).
- Understand Detection vs Prevention mode and rule precedence.
- Be ready to explain why association is necessary: Without association, a WAF policy is inactive.
✅ Summary Table for Exam
| Concept | Key Point |
|---|---|
| WAF Policy | Defines rules to protect apps |
| Association | Connects policy to a resource to activate it |
| Resources Supported | Azure Front Door, Application Gateway |
| Modes | Detection (log only), Prevention (block attacks) |
| Custom Rules | Take precedence over managed rules |
| Managed Rules | Default protection like OWASP CRS |
