How to Properly Implement the Azure Web Application Firewall

Introduction

Web applications are now the primary interfaces between businesses and customers. With the rising number of threats – from SQL Injection to Cross-Site Scripting (XSS) – the need for protection mechanisms directly at the application layer is increasing.

Microsoft Azure provides the Web Application Firewall (WAF), which integrates seamlessly with services such as Application Gateway, Azure Front Door, and Azure CDN.

Why is a Web Application Firewall needed?

A Web Application Firewall (WAF) is a security component designed to monitor, filter, and block HTTP(S) traffic between clients and web applications. It typically operates at Layer 7 (Application Layer) of the OSI model, detecting attacks based on predefined rules, signatures, or anomaly-based behavior.

It protects against attacks such as:

• Injection Attacks: The WAF analyzes parameters, headers, and payloads of HTTP requests. Suspicious inputs like UNION SELECT or path traversal attacks are blocked or neutralized with special escaping mechanisms before reaching the backend application.
• Cross-Site Scripting (XSS): The WAF filters malicious payloads in input fields or URL parameters, preventing them from being passed on to other users’ browsers.
• Session Hijacking: By inspecting cookies and session IDs, the WAF can identify unusual usage patterns, validate tokens, or block manipulated requests.
• Data Exfiltration via Insecure APIs: The WAF monitors data flows and detects attempts to extract sensitive information or exfiltrate large volumes of data via API endpoints.
• Application-level DDoS Attacks: Unlike traditional network firewalls, a WAF can detect application-specific anomalies. It can limit requests per IP or enforce rate limiting to prevent service overload.

How can a Web Application Firewall be deployed?

An Azure Web Application Firewall (WAF) can be deployed in several ways, such as through the Azure Portal, via the Azure CLI, or automated with Infrastructure-as-Code (IaC).

Depending on requirements, an Azure Application Gateway with load balancing can be used for regional applications, while Azure Front Door is suitable for global applications. For both options, the Azure Web Application Firewall can then be enabled.

Preparation Phase

Before putting a Web Application Firewall (WAF) into active Prevention Mode, a structured planning and testing phase is essential.

In this stage, the WAF runs in Detection Mode. Suspicious requests are logged but not blocked. This allows detailed traffic analysis without disrupting operations or affecting legitimate users. Based on the logs, false positives can be identified, and rule sets can be fine-tuned.

Identifying the Blast Radius

Before switching a WAF to Prevention Mode in production, it’s important to assess the potential impact (“Blast Radius”) on operations. All protected web applications and APIs should be identified first:

• Existing endpoints: Applications and services already integrated into Application Gateway or Front Door.
• Future endpoints: Planned web apps and APIs that will also require protection.

This complete overview enables:

• Impact analysis: Assessing how Prevention Mode would affect live traffic for each application.
• Documentation: Recording effects (e.g., false positives, performance implications) during the testing and migration phases.
• Communication: Sharing concrete findings and recommendations with workload teams so that applications can be adapted early or whitelists and custom rules can be added.

Rule Set Definition

Azure Web Application Firewall (WAF) supports both Managed Rule Sets (MRS) and Custom Rules.

Managed Rule Sets are based on the OWASP Core Rule Set (CRS) and cover a wide range of common attack vectors such as SQL Injection, XSS, or Remote Code Execution. Each rule belongs to a category – for example, SQL Injection rules start with ID 942xxx, while XSS rules are grouped under 941xxx.

In practice, it is important not only to enable these rules but also to refine them, as false positives may occur. Azure allows you to disable individual rules or apply exclusions to skip specific headers, fields, or parameters. This way, protection remains active without blocking legitimate traffic. Azure also provides different CRS versions, which can be selected depending on testing status and application compatibility.

While Managed Rule Sets address generic threats, Custom Rules tailor the WAF to the specific application. Each rule has a priority that determines its evaluation order. Actions include Allow, Block, Log, and for Front Door also Redirect. Different operators allow granular control:

• IPMatch for IP ranges or CIDR blocks,
• GeoMatch for IP-based geolocation,
• StringMatch and RegexMatch for inspecting query strings, headers, or URIs,
• SizeConstraint for request size limits,
• RateLimitRule to mitigate Layer 7 DDoS attacks.

Common use cases include defining IP ranges to explicitly allow trusted networks or block known attacker sources, as well as HTTP header checks (e.g., ensuring requests use application/json or blocking suspicious user agents). Query strings and URL paths can also be restricted – for example, limiting access to admin endpoints to internal networks or blocking dangerous extensions such as .php in a .NET environment.

The best practice for defining rules follows a detection-first approach: new rules should first be deployed in Detection Mode to observe their behavior and identify false positives. Only after sufficient validation should they be enabled in Prevention Mode. A least-privilege approach is recommended – starting with restrictive settings and then adding exceptions as needed. To maintain traceability, all changes should be version-controlled, resulting in a transparent, reproducible, and governance-compliant security setup.

How Rule Sets Evaluate Requests

A WAF uses rule sets to decide whether incoming HTTP(S) requests should be allowed, logged, or blocked. These consist of default managed rules plus optional custom rules. The evaluation mechanisms include:

Signature and Pattern Matching:

• Requests are checked against known attack patterns.
• Suspicious sequences in URLs, bodies, headers, or cookies are flagged.

Positive Security Model (Whitelist):

• Only explicitly allowed requests are permitted; everything else is blocked or logged.
• Best suited for highly regulated APIs or sensitive applications.

Negative Security Model (Blacklist):

• Known malicious requests are blocked.
• Legitimate but new or unusual requests might slip through if not covered.
• Commonly used in combination with whitelisting.

Custom Rules:

• Can be based on IP addresses, geolocation, headers, methods, or rate limits.

OWASP CRS Anomaly Scoring (Function & Tuning):

• Instead of blocking immediately, CRS assigns an anomaly score for each finding.
• Each rule has a severity: Critical = 5, Error = 4, Warning = 3, Notice = 2.
• Requests exceeding thresholds are blocked:
• Inbound: block ≥ 5
• Outbound: block ≥ 4

Example:

• XSS rule hit (Critical → +5)
• Minor HTTP anomaly (Warning → +3)
• Total = 8 → exceeds inbound threshold → blocked in Prevention, only logged in Detection.

Paranoia Level (PL) controls strictness: PL1–PL4 progressively enable stricter rules. Higher levels increase both security and the likelihood of false positives.

Activating Detection Mode

In Detection Mode, the WAF only monitors traffic – suspicious requests are logged but not blocked.

Benefits:

• Identify false positives without disrupting live traffic.
• Analyze real attack patterns targeting your application.
• Risk-free introduction: workload teams can observe WAF behavior without production impact.

Transition Phase

This phase moves the WAF from passive Detection Mode to active Prevention Mode – crucial for balancing strong attack protection with minimal disruption to legitimate traffic.

Analyzing Findings in Detection Mode

During Detection Mode, all suspicious requests are logged. These logs form the basis for rule adjustments. WAF events are centralized in Azure Monitor or Log Analytics, including request URL, headers, IP, user agent, rule IDs, and anomaly scores. Common patterns (e.g., SQL injection attempts on login pages, XSS in search fields) reveal the attack surface. Some hits may be irrelevant or false positives.

Configuring Custom Rules

When default rules (e.g., OWASP CRS) are too strict or insufficient, Custom Rules can be defined. These are evaluated before Managed Rule Sets.

Examples:

• Whitelisting internal API clients (IP ranges, service identities).
• Blocking specific user agents such as bots or scrapers.
• Geo-blocking to restrict traffic to selected regions.
• Rate limiting to prevent abuse.

Custom Rules are configured via Azure WAF policies, each with conditions (match criteria) and an action (Allow, Block, Log).

Activating Prevention Mode

After successful testing and adjustments, the switch to Prevention Mode happens:

• Active blocking: suspicious requests exceeding thresholds or matching custom rules are blocked.
• Ongoing fine-tuning: logs should still be monitored to catch new attack patterns or false positives.
• Gradual rollout: in critical environments, activation can be endpoint- or app-specific to limit the blast radius.

From this point, the WAF becomes an active security layer between clients and applications.

Continuous Optimization

Deploying a WAF is not a one-time project – it requires ongoing security operations. Regular analysis, visualization, and automation ensure strong protection and adaptation to new attack methods.

Visualizing Results

FrontDoorAccessLogs and FrontDoorAuditLogs can be visualized in different ways:

• Azure Workbooks: build interactive dashboards.
• Security dashboards: provide unified visibility into blocks, attack frequency, and potentially compromised endpoints.
• Long-term trend analysis: useful for budgeting and capacity planning.

Alerts for Unusual Activity

• Azure Monitor Alerts: automatic triggers when thresholds are exceeded (e.g., blocked requests per minute).
• Microsoft Sentinel Integration: advanced analysis with correlation across other security events.
• SIEM Integration: full SOC workflows to assess attacks in the context of endpoint and network security.

Conclusion

The Azure Web Application Firewall (WAF) is a critical security tool for modern web applications and APIs. It protects against SQL Injection, XSS, session hijacking, data exfiltration, and more – directly at the application layer.

Success comes from a structured approach:

1. Planning: identify workloads and assess the blast radius.
2. Testing: run in Detection Mode to analyze attacks and false positives.
3. Transition: implement custom rules and gradually enable Prevention Mode.
4. Optimization: continuously monitor, visualize, and fine-tune rules.

Organizations that follow this methodology reduce risk, avoid outages from misconfigurations, and gain transparency into threats affecting their applications.

Helpful Links for Further Research

• Azure Application Gateway WAF
• Azure Front Door WAF
• OWASP Core Rule Set (CRS)
• Azure Monitor and Log Analytics
• Microsoft Sentinel