Skip to main content
Azure Web Application Firewall (WAF) ships with a Microsoft-managed Default Rule Set (DRS). The DRS is based on the OWASP Core Rule Set and is continuously updated to protect against common web threats. It provides out-of-the-box defenses so you do not have to create signatures for every attack pattern. Key protections included in the managed Default Rule Set:
  • Cross-site scripting (XSS)
  • SQL injection (SQLi) and PHP injection
  • Remote code execution (RCE)
  • Local file inclusion (LFI) and remote file inclusion
  • Java-specific attacks
  • Protocol-level attacks such as HTTP request smuggling and response splitting
  • Session fixation and other session-related attacks
Each managed rule detects a signature or pattern and applies the WAF action configured for that rule (for example, Block on Anomaly or Log). You can enable or disable individual rules or entire rule groups to tune protection for your application while keeping baseline coverage.
A slide showing a Web Application Firewall default rule set, with a left column of threat categories and a right-hand table listing specific attack types (e.g., SQL injection, HTTP request smuggling, PHP injection) alongside their actions, status, and rule groups. Most rules are set to "Block on Anomaly" and shown as enabled.
In this article we demonstrate how the Default Rule Set blocks a cross-site scripting (XSS) attack by deploying Azure Front Door (Premium) with a WAF policy in front of a deliberately vulnerable web application and observing the blocking behavior.

​
App setup and vulnerable application

For this demo we use two simple Azure App Services that intentionally contain an XSS vulnerability. Both apps accept text fields (for example, “name” and “comment”) and do not sanitize input, so injecting script payloads executes in the browser. The apps are deployed to two regions (primary in East US and secondary in West Europe) so we can validate global routing and origin failover via Front Door.
The screenshot shows the Microsoft Azure "App Services" page listing two web apps (webapp-waf-primary and webapp-waf-secondary) both with status "Running" and a Free pricing tier. The apps are located in East US and West Europe and belong to the Kodekloud Labs subscription.
Common XSS test payloads
  • Use these payloads in the app’s input fields to verify XSS behavior.
<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
<iframe src="javascript:alert('XSS')"></iframe>
javascript:alert('XSS')
When the app is vulnerable, submitting one of these payloads causes an alert popup in the browser, confirming remote script execution:
A browser window showing a small pop-up alert from webapp-waf-primary-wrygno.azurewebsites.net that reads "XSS" with an OK button. A mouse cursor is pointing at the dialog against a pale grey background.

​
Deploying Front Door with WAF

To protect these apps, create an Azure Front Door (Premium) profile and add the App Services as origins. You can attach an existing WAF policy during Front Door creation or create a WAF policy as a separate resource and associate it with multiple Front Door endpoints for centralized control. When using the Quick Create experience for Front Door:
  • Choose the Premium tier for WAF and advanced security features.
  • Set origin type to “App services” and select your primary web app.
  • Optionally create a new WAF policy and attach it during deployment.
A screenshot of the Microsoft Azure portal showing the "Create a Front Door profile" form with Profile details and Endpoint settings. The Premium tier is selected and fields visible include endpoint name/hostname, origin type (App services), origin host name, private link option, caching, and a WAF policy.
After the profile is created, add the secondary App Service to the origin group so Front Door can route traffic across both regions and perform health probes for failover.
A screenshot of the Microsoft Azure portal showing the "Update origin group" dialog for an Azure Front Door profile, listing two origin hosts (primary and secondary webapps) with health probes enabled. The left navigation pane highlights "Origin groups" within the Front Door resource.

​
WAF policy, associations, and managed rules

Open the WAF policy resource you attached to Front Door. The WAF policy overview shows whether the policy is Enabled and whether it is in Detection (logs only) or Prevention (actively blocks) mode. The Associations section lists the Front Door profiles and endpoints that the policy protects.
Screenshot of the Microsoft Azure portal showing the "waf01 | Associations" page for a Front Door WAF policy, listing front door profiles (afd-waf, afd-xss-site) and options to associate or remove profiles. A right-hand pane titled "Associate a Front door profile" is open with a Domain selector and Add/Cancel buttons.
Managed rules are organized by attack category (XSS, SQLi, LFI, RCE, protocol attacks, etc.). You can enable or disable rule groups or individual rules. Microsoft updates these managed rules to reflect new threat signatures.
A screenshot of the Microsoft Azure portal open to a Front Door WAF policy page titled "waf01 | Managed rules," showing a list of XSS-related managed rules, their IDs, actions (e.g., Block on Anomaly) and enabled statuses. The left menu highlights "Managed rules" and "Custom rules," and a notification in the top-right says the origin group was updated.
Policy mode matters. Start in Detection mode to observe which rules trigger for your app, then switch to Prevention when you are confident rules won’t cause false positives.
A screenshot of the Microsoft Azure portal showing the "waf01" Front Door WAF policy Overview page, with essentials like resource group, status (Enabled) and policy mode (Detection) displayed. The page also shows tiles for Policy settings, Managed rules, Custom rules, and Associations.
Enable diagnostics (send WAF logs to Azure Monitor/Log Analytics) while in Detection mode to evaluate which managed rules fire against your application before switching to Prevention. This helps avoid false positives impacting legitimate traffic.
Managed rules at a glance
  • Use this quick reference to understand what the Default Rule Set covers.
Resource TypeTypical Use Case
XSS rulesBlock attempts to inject executable script into pages
SQLi rulesDetect and block SQL injection payloads
RCE / LFI rulesPrevent remote/local file inclusion and code execution patterns
Protocol rulesMitigate HTTP request smuggling, response splitting
Language-specific rulesProtect against Java/.NET/PHP-specific vulnerabilities
Session rulesDefend against session fixation and related attacks

​
Testing the WAF: XSS blocked

Once Front Door and the WAF policy are associated, and the WAF is set to Prevention mode, submit an XSS payload through the Front Door endpoint to the vulnerable application. The WAF inspects the request and blocks it if it matches an XSS managed rule. When blocked, the browser typically receives an HTTP 403 Forbidden response. Use the browser developer tools (Network tab) to confirm:
  1. The request URL contains the injected payload.
  2. The response status code is 403.
  3. Response and request headers indicate the request was intercepted by Front Door/WAF.
A browser screenshot showing a webpage that reads "The request is blocked." on the left. On the right the developer tools Network panel is open, listing a failed request (403) and other network entries.
Example request/response headers (truncated) when the WAF blocks an XSS attempt: 
General
Request URL: https://afd-xss-site-dnh5grfeg2edbacn.z03.azurefd.net/?name=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E&comment=
Request Method: GET
Status Code: 403 Forbidden
Remote Address: 13.107.246.62:443
Referrer Policy: strict-origin-when-cross-origin

Response Headers
Cache-Control: no-store
Content-Length: 1484
Content-Type: text/html
Date: Fri, 29 Aug 2025 07:15:24 GMT
X-Azure-Ref: 20250829T071524Z-17f98659fdfm5lpwhC1DOHt3uc00000001tg00000002md3
X-Cache: CONFIG_NOCACHE

Request Headers
:authority: afd-xss-site-dnh5grfeg2edbacn.z03.azurefd.net
:method: GET
:path: /?name=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E&comment=
:scheme: https
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Referer: https://afd-xss-site-dnh5grfeg2edbacn.z03.azurefd.net/?name=&comment=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E
Sec-CH-UA: "Opera";v="120", "Not-A.Brand";v="8", "Chromium";v="135"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "macOS"
Sec-Fetch-Dest: document
This confirms the managed rules detected the injected script and prevented it from reaching the backend application.

​
Custom rules and other scenarios

Managed rules cover most common threats, but you may need custom rules for scenarios such as:
  • Geofencing (block or allow traffic by country)
  • IP allow/deny lists
  • Application-specific exceptions or rate limits
In Azure WAF for Front Door, custom rules are evaluated before managed rules. That means custom rules can short-circuit or override managed rules when needed. Use custom rules carefully to avoid unintentionally disabling protective behavior.
Do not permanently disable certificate validation on origins in production. Disabling certificate validation may be acceptable temporarily for troubleshooting, but it weakens the security of your origin connections and should not be used as a long-term solution.

​
Summary

  • Azure WAF’s Default Rule Set (DRS) provides baseline protections for a wide range of web attacks and is managed and updated by Microsoft.
  • Managed rules can be enabled/disabled at both the group and individual rule level to tune security.
  • Start in Detection mode with diagnostics to validate which rules fire, then switch to Prevention mode to actively block attacks.
  • Use custom rules for specific application requirements (e.g., geofencing or bespoke allowlists). Custom rules take priority over managed rules.
  • Deploying Front Door (Premium) + WAF is an effective architecture to protect global web applications (App Services, VMs, and other backends).
Links and references

Watch Video