General Availability of JavaScript Challenge in Azure Front Door WAF
We are pleased to announce the General Availability (GA) of the JavaScript Challenge feature for Azure Web Application Firewall (WAF) on Azure Front Door. This capability equips organizations with a seamless, invisible anti-bot verification layer that distinguishes legitimate users from malicious scripts helping protect web applications from automated threats while preserving a smooth user experience. Azure WAF JavaScript Challenge Modern bot attacks are increasingly evasive, often bypassing traditional defenses like IP based blocking or simple rate limits. The JavaScript Challenge introduces a lightweight, browser-based verification step that helps distinguish legitimate users from automated scripts without requiring user interaction. Benefits of the JavaScript Challenge include: Low friction for legitimate users: Genuine users experience minimal latency or interruption since no manual interaction is required. Stronger bot protection: Automated tools and scripts fail to pass the computational challenge, enabling more effective blocking of bad bots. Flexible enforcement: You can target specific endpoints (e.g., login, registration, checkout flows), apply to bot manager or custom rules, and adjust cookie lifetimes to align with your user experience goals. How JavaScript Challenge Works The JavaScript Challenge is configured as an action in either custom rules or in the Bot Manager ruleset. When a client’s HTTP/S request matches a rule with this action, Azure WAF directs the browser to a lightweight challenge page. The page runs a short computational task automatically usually invisible to the user. If the browser successfully completes the computation, the request is validated and allowed to proceed, confirming that it originated from a legitimate user. If the challenge fails, the request will be blocked, preventing automated bots from accessing the application. Getting Started If you have been using JavaScript Challenge during the public preview, your existing configurations will continue to work. For new users, simply enable the JavaScript Challenge action in your WAF policy and define the triggering conditions. For more details on configuration and best practices, check out our earlier blogs: Azure WAF Public Preview: JavaScript Challenge | Microsoft Community Hub Azure WAF’s Bot Manager 1.1 and JavaScript Challenge: Navigating the Bot Threat Terrain | Microsoft Community Hub Documentation Web Application Firewall JavaScript Challenge | Microsoft LearnPublic Preview: Custom WAF Block Status & Body for Azure Application Gateway
Introduction Azure Application Gateway Web Application Firewall (WAF) now supports custom HTTP status codes and custom response bodies for blocked requests. This Public Preview feature gives you more control over user experience and client-side handling, aligning with capabilities already available on Azure Front Door WAF. Why this matters Previously, WAF returned a fixed 403 response with a generic message. Now you can: Set a custom status code (e.g., 403, 429) to match your app logic. Provide a custom response body (e.g., a friendly error page or troubleshooting steps). Ensure consistency across all blocked requests under WAF policy. This feature improves user experience (UX), helps with compliance, and simplifies troubleshooting. Key capabilities Custom Status Codes: Allowed values: 200, 403, 405, 406, 429, 990–999. Custom Response Body: Up to 32 KB, base64-encoded for ARM/REST. Policy-level setting: Applies to all blocked requests under that WAF policy. Limit: Up to 20 WAF policies with custom block response per Application Gateway. Configure in the Azure Portal Follow these steps: Sign in to the https://portal.azure.com. Navigate to your WAF Policy linked to the Application Gateway. Under Settings, select Policy settings. In the Custom block response section: Block response status code: Choose from allowed values (e.g., 403 or 429). Block response body: Enter your custom message (plain text or HTML). Save the policy. Apply the policy to your Application Gateway if not already associated. Configure via CLI az network application-gateway waf-policy update \ --name MyWafPolicy \ --resource-group MyRG \ --custom-block-response-status-code 429 \ --custom-block-response-body "$(base64 custompage.html)" Configure via PowerShell Set-AzApplicationGatewayFirewallPolicy ` -Name MyWafPolicy ` -ResourceGroupName MyRG ` -CustomBlockResponseStatusCode 429 ` -CustomBlockResponseBody (Get-Content custompage.html -Encoding Byte | [System.Convert]::ToBase64String) Tip: For ARM/REST, the body must be base64-encoded. Best practices Use meaningful status codes (e.g., 429 for rate limiting). Keep the response body lightweight and informative. Test thoroughly to ensure downstream systems handle custom codes correctly. Resources Configure Custom Response code Learn more about Application Gateway WAFGeneral Availability of CAPTCHA in Azure Front Door WAF
We are excited to announce the General Availability (GA) of the Azure Web Application Firewall (WAF) CAPTCHA challenge for Azure Front Door, empowering customers to better defend their web applications against automated bot attacks while ensuring legitimate users can still access their apps seamlessly. This milestone marks the culmination of a successful public preview that saw hundreds of customers defend against more than 700 million bot requests, reinforcing the value of interactive security mechanisms in modern web application protection. Why CAPTCHA Matters Web applications today face an ever-growing array of automated threats - bots, scrapers, credential stuffing, and brute-force attacks - that often bypass traditional defenses like IP blocking and rate limiting. CAPTCHA introduces a human verification layer that helps distinguish legitimate users from malicious automation. With this GA release, Azure Front Door WAF now offers a fully supported CAPTCHA action that can be configured in custom rules or Bot Manager rules. When suspicious traffic matches a CAPTCHA-enabled rule, users are prompted with a visual or audio challenge to verify their identity before proceeding. How CAPTCHA Works When a client request matches a WAF rule that has the CAPTCHA action enabled, Azure WAF displays an interactive CAPTCHA challenge in the browser to verify that the requester is human. If the user successfully solves the CAPTCHA, Azure WAF marks the request as validated and allows it to proceed through the rest of the rule evaluation. Requests that don’t complete the challenge (or fail it) are blocked, stopping automated bots from advancing. What’s New in GA With the GA release, customers can expect: Updated Interstitial Page: The CAPTCHA page now includes refreshed Microsoft branding, delivering a more consistent and trusted experience for users. Enhanced Stability and Performance: Improvements based on feedback from preview deployments to ensure faster response times and smoother user verification experiences. Full Production Support: The feature is now backed by Microsoft’s service-level agreement (SLA) and is recommended for all production workloads. How to Get Started If you have already been using CAPTCHA during the public preview, no action is needed, your configurations will continue to work as expected. For new users, simply enable the CAPTCHA action within your custom rules or managed rule sets and define the triggering conditions. For a deeper dive into how CAPTCHA works and how to configure it, check out our earlier blogs: Securing web applications with Azure Front Door WAF CAPTCHA | Microsoft Community Hub Public Preview of Azure WAF CAPTCHA Challenge for Azure Front Door | Microsoft Community Hub Documentation Azure Front Door Web Application Firewall CAPTCHA | Microsoft LearnSecuring web applications with Azure Front Door WAF CAPTCHA
Introduction Web applications today are constantly under siege from a range of threats, including automated bots and scrapers, as well as credential-focused threats such as credential stuffing and brute-force attacks. As attackers leverage advanced automation and increasingly sophisticated attack methods, organizations need more robust and interactive security measures capable of distinguishing between legitimate users and malicious traffic. To address these evolving challenges, Azure Front Door’s Web Application Firewall (WAF) now introduces CAPTCHA, currently available in public preview. This feature incorporates a critical interactive verification step, validating real human users while blocking automated malicious traffic in real-time. By integrating CAPTCHA directly within the WAF, organizations can secure crucial user flows - such as logins, registrations, and checkout processes - from bots and scripted attacks aiming to compromise credentials, create fraudulent accounts, or harvest data, all while preserving a seamless experience for genuine users. Overview of Azure WAF Front Door CAPTCHA CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a security mechanism designed to differentiate human users from automated bots by presenting interactive challenges that only humans can reliably complete. Azure Front Door’s WAF implementation of CAPTCHA delivers this capability seamlessly, integrating directly into web traffic processing to offer real-time protection. Azure Front Door WAF CAPTCHA is a dynamic security challenge automatically triggered when a client's request matches a WAF rule configured with the CAPTCHA action. When activated, users are presented with an interactive CAPTCHA challenge in their browser and can verify themselves either by solving a visual puzzle or completing an audio-based task. Once successfully solved, the user's request proceeds normally, while automated scripts and bots unable to complete the challenge are immediately blocked, effectively preventing malicious traffic. By clearly distinguishing human users from bots, Azure WAF CAPTCHA strengthens application defenses. Key benefits include: Account and Access Protection - Azure WAF CAPTCHA helps protect authentication and user account workflows from automated abuse and unauthorized access. Block Automated Account Creation - Stops bots from registering fake or spam accounts during sign-up. Prevent Account Takeovers - Stop suspicious login attempts to protect against stolen credentials. Stop Brute-Force Logins - Prevents automated password guessing and account breaches Data and Resource Protection - Use CAPTCHA to defend web content and inventory from unauthorized scraping and resource hoarding. Limit Web Scraping - Restricts bots from extracting proprietary data like pricing or content. Prevent Inventory Hoarding - Protects e-commerce and ticketing platforms from bulk purchasing by bots. Fraud and Abuse Prevention – Use CAPTCHA to reduce the risk of automated abuse in transaction and engagement workflows. Block Fake Transactions - Stops abuse of discounts, gift cards, or loyalty programs by scripted bots. Reduce Spam and Abusive Inputs - Ensures form and comment submissions are from real users, not bots. Application-Layer DDoS Defense- Acts as a first line of defense to block high-volume bot requests targeting application resources. Azure WAF Front Door CAPTCHA Key Features Azure WAF CAPTCHA in Azure Front Door is designed to be flexible, easy to configure, and deeply integrated into WAF’s existing policy model. Below are the key features that define how CAPTCHA is activated, managed, and monitored. Policy Settings Azure WAF CAPTCHA includes a configurable policy setting that defines how long a user remains validated after successfully completing a challenge. This is controlled through the CAPTCHA challenge cookie, which is injected into the user's browser upon solving the challenge. The cookie name is afd_azwaf_captcha and it determines how long a user is exempt from repeated challenges. The cookie validity period can be set between 5 and 1,440 minutes, with a default of 30 minutes. Once the cookie expires, the user will be prompted to complete the CAPTCHA again if they trigger a matching rule. This setting helps balance security and user experience by reducing repetitive challenges for legitimate users while still enforcing protection over time. Integration with Bot Manager Rules CAPTCHA can be enabled directly in the Bot Manager rulesets, allowing administrators to apply CAPTCHA as an enforcement action. To enable the CAPTCHA challenge within the Bot Manager's managed rules, users can navigate to the managed rules section in their WAF policy and adjust the actions for each rule group. This setup is ideal for mitigating automated logins, credential stuffing, and other bot-driven behaviors with minimal configuration. Custom Rule Support For more targeted scenarios, CAPTCHA can be configured as the action in a custom rule. This allows precise control over when and where the challenge is triggered - based on URI, method, headers, geo-location, or user-agent patterns. Common examples include applying CAPTCHA to login endpoints, sign-up forms, or regions known for bot traffic. Monitoring Detailed logs and metrics are captured whenever the CAPTCHA challenge is triggered. This allows security administrators to track the CAPTCHA challenges and analyze traffic patterns and security incidents. The “Web Application Firewall CAPTCHA Request Count” metric within Azure Front Door displays the number of CAPTCHA requests evaluated by the Web Application Firewall: When WAF diagnostic logging is enabled, each CAPTCHA event is written to the AzureDiagnostics table. These logs can be queried to see which endpoints triggered challenges, the outcome of each event (Issued, Passed, Valid, or Blocked), the client IP and user agent, and the timestamp of the interaction. By analyzing this data, you can calculate solve rates, identify problem spots where users are repeatedly challenged or blocked, and fine-tune your rules to improve both security and user experience. Pricing Azure Front Door WAF CAPTCHA is currently in public preview and pricing details are available on Pricing - Front Door | Microsoft Azure. Enabling and using the CAPTCHA challenge CAPTCHA in the Bot Manager ruleset As described in the previous section, the CAPTCHA challenge can be enabled within both the Bot Manager ruleset and custom rules. To enable it within the Bot Manager ruleset, simply navigate to the Managed Rules section of your WAF policy in Azure Front Door, select the Bot Manager rule you want to configure, and change the action to CAPTCHA challenge. Within the Policy Settings, you can adjust the CAPTCHA challenge cookie’s validity period, with options ranging from 5 to 1,440 minutes. To demonstrate how Azure WAF Front Door issues a CAPTCHA challenge via a Bot Manager rule, we will simulate bot-like requests using PowerShell. In our setup, we have configured Azure Front Door with a WAF Policy that has the Bot Manager 1.1 ruleset enabled and action set to CAPTCHA for the rules - Bot100100 (Malicious bots detected by threat intelligence) and Bot100200 (Malicious bots that have falsified their identity). Behind this Azure Front Door, a web application is running and is actively protected by the WAF. We use two PowerShell snippets—one sending a known crawler User-Agent, the other spoofing a high-risk IP via X-Forwarded-For—to trigger the CAPTCHA rule. You can use Postman, Visual studio, or any other HTTP client to send these requests; this example uses PowerShell. From the results we observe a 403 Forbidden status code in both cases, indicating that WAF issued the CAPTCHA challenge and then blocked the request because no valid token was returned. In the Front Door WAF diagnostic logs, we can view the requests: This confirms that the Bot Manager rule correctly triggered the CAPTCHA action and enforced a block since the client could not complete the interactive challenge. CAPTCHA in custom rules For custom rules, you define exactly when the CAPTCHA challenge appears by creating a match-type or rate limit rule with action set to CAPTCHA. In the custom rule’s Policy Settings, you can also configure the CAPTCHA cookie lifetime - anywhere from 5 to 1,440 minutes - so that users remain validated for the duration you choose. To demonstrate the CAPTCHA challenge in action, we set up a simple scenario using Azure Front Door with a WAF policy with our custom rule created above. Behind the Front Door endpoint, a demo web application is running. The rule inspects the RequestUri and issues a CAPTCHA challenge when the URI contains /ftp. In Policy Settings, we set the CAPTCHA cookie validity to 5 minutes. In our browser, we navigate to our web application and click on the link that leads to the /ftp path. The browser briefly displays the CAPTCHA form, confirming that the challenge is active. We are presented with the CAPTCHA challenge page, select the puzzle option and proceed to solve it: After solving the puzzle, the afd_azwaf_captcha cookie appears under Response Headers. The same cookie will be sent with each subsequent request, preventing repeated challenges within the cookie lifetime and ensuring smooth navigation. The Front Door WAF logs provide detailed insights into CAPTCHA challenge requests, showing the issued, passed challenges as well as active challenges: Conclusion Malicious bots continue to threaten web applications with automated account creation, credential abuse, and data scraping. Azure Front Door WAF’s CAPTCHA challenge delivers an interactive verification step that stops sophisticated bots at the edge, complementing Bot Manager and JavaScript challenge protections. By issuing puzzles or audio challenges only on high-risk requests and tracking outcomes through built-in metrics and logs, CAPTCHA ensures genuine users navigate your site without interruption while blocking automated attacks. Together, these features provide a powerful, adaptive defense against evolving bot threats, helping organizations maintain application integrity and deliver a seamless experience for real users. References Introduction to Azure Web Application Firewall | Microsoft Learn Public Preview of Azure WAF CAPTCHA Challenge for Azure Front Door | Microsoft Community Hub Azure Front Door Web Application Firewall CAPTCHA (preview) | Microsoft Learn Web Application Firewall (WAF) on Azure Front Door | Microsoft Learn Web application firewall custom rule for Azure Front Door | Microsoft LearnHow Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hubMonitoring web application traffic for configuring rate limit on Azure Front Door WAF
Introduction Azure Web Application Firewall (WAF) is a cloud-native service that actively protects web applications from common vulnerabilities and exploits. It also supports custom rules that allow fine-grained control over traffic. Among these custom rules is the rate-limiting feature available in both Azure Application Gateway and Azure Front Door. Rate limiting helps mitigate denial-of-service (DoS) attacks, prevents abuse from misconfigured clients sending excessive requests, and controls traffic from specific geographies. By limiting requests per client in a set time window, WAF keeps your app available and responsive even under heavy load. While rate limiting is a powerful tool for safeguarding web applications, some users struggle with configuring appropriate thresholds and durations. These two values often require tuning based on actual traffic patterns. Without proper planning or visibility into real traffic patterns, rate limit settings often end up being: Too strict – Blocking legitimate users and degrading user experience. Too lenient – Failing to stop abusive or malicious traffic. This blog is the first in a two-part series designed to help users configure rate limiting in Azure Web Application Firewall (WAF). In this first part, we focus on Azure Front Door WAF and demonstrate how to use diagnostic logs to make informed, data-driven decisions about rate limit thresholds and durations. By analyzing real traffic patterns, you can configure rate limits that strike the right balance between security and usability, protecting your application without disrupting legitimate users. Understanding rate limiting in Azure Front Door WAF At its core, rate limiting is a mechanism that restricts the number of requests a client can make to a web application within a specified period. This helps prevent issues like brute-force login attacks, automated bots scraping data, or sudden traffic spikes. Azure Front Door WAF applies rate limiting through custom rules that monitor incoming requests according to specific match conditions. Key characteristics of rate limiting in Azure Front Door WAF include: Duration: Can be set to 1 or 5 minutes. Threshold: Number of requests allowed in the time window. Customizability match conditions: You can match based on country (geolocation), IP address (remote address or socket address) request URI, HTTP method, and more. Action: What to do when the threshold is exceeded e.g., deny, log, redirect, JS Challenge (preview), CAPTCHA (preview). Below is an example of a rate limit rule configured in Azure Front Door WAF: Using diagnostic logs to configure WAF rate limiting To configure effective rate limiting policies in Azure Front Door WAF, it is important to understand how users are accessing your application. Diagnostic logs from Azure Front Door provide this visibility. In this section, we’ll walk through: Enabling diagnostic logs Querying traffic patterns with KQL Using insights to define smart thresholds and durations Enable diagnostic logs In Azure Front Door: Go to your Front Door profile. Under Monitoring, select Diagnostic settings. Click + Add diagnostic setting. Add a new setting to capture: FrontDoor Access Log – request level data. FrontDoor WebApplicationFirewall Log – WAF rule matches. Send logs to: Log Analytics workspace (recommended for querying), Storage account, or Event Hub. Save the settings. When configuring rate limit rules in Azure Front Door WAF, you can choose either a 1-minute or 5-minute time window. While both options are supported, using a 5-minute window with a higher threshold can improve detection accuracy by reducing false positives. Rate limiting is applied per socket IP - the source IP as seen by Azure Front Door. If there's another CDN or proxy in front of Front Door, this IP may not represent the original client, which can affect how rate limits are enforced. Please refer to Web application firewall rate limiting for Azure Front Door | Microsoft Learn. Analyze traffic behavior with KQL With diagnostic logs flowing into your log analytics workspace, you can begin to understand actual request volumes, IP behavior, and trends across time. These insights form the basis for defining effective rate limits. Query 1: Average requests per IP (5-minute intervals) This first query provides the average number of requests each client IP sends over 5-minute windows. It helps establish a baseline of expected activity per user. Understanding the average request rate helps you distinguish between normal and abnormal behavior. It’s your starting point for setting a rate limit that won’t block legitimate users. AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestsPerIP = count() by clientIp_s, bin(TimeGenerated, 5m) | summarize AvgRequestsPerIP = avg(RequestsPerIP) by bin(TimeGenerated, 5m) | order by TimeGenerated asc Usage: Set your initial rate limit slightly above the observed average to allow for minor bursts while still preventing abuse. The screenshot below shows the average number of requests per IP in 5-minute intervals from our Azure Front Door demo environment within a 7-day period. Most intervals fall between 1 to 5 requests per IP, indicating normal user behavior. However, there are occasional spikes, such as 15.5 requests at 4:10 PM and a significant burst of 459 requests at 4:15 AM. This highlights the importance of using real data to set thresholds. While a baseline of 20–30 requests per 5 minutes would cover typical traffic, it would still catch outlier spikes like these that may indicate abuse or automation. Query 2: Max requests seen from a client IP (5-minute window) This query surfaces the maximum number of requests observed from any individual IP address in a single 5-minute time window. This helps you understand peak load behavior, which could be from a legitimate spike or a potential abuse/bot. AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestsPerIP = count() by clientIp_s, bin(TimeGenerated, 5m) | summarize MaxRequestsPerIP = max(RequestsPerIP) by clientIp_s | order by MaxRequestsPerIP desc Usage: Use this to define an upper threshold for rate limiting. To avoid overfitting outliers, consider setting your limit near the 95th percentile of these max values. The screenshot below shows the results of the KQL query executed in my demo environment using Azure Front Door diagnostic logs within a 7-day period. As observed, the most active IP (35.X.X.X) recorded a peak of 459 requests within a 5-minute window, which is significantly higher than the rest. The second highest IP peaked at 106 requests, and most of the client IPs fell well below 30 requests per 5 minutes. This distribution highlights an important insight: while most users exhibit moderate request behavior, a few outliers can generate large bursts. These outliers could be misconfigured clients, aggressive bots, or potential abuse cases. When configuring rate limits, it’s advisable to base your threshold not on the absolute maximum (459), but rather on a statistical percentile such as the 90th or 95th percentile. In this case, a reasonable threshold might be around 120–150 requests per 5 minutes, allowing headroom for legitimate high-traffic users while still blocking abnormal spikes. Query 3: Most active IP per country (Geo-aware limit tuning) This query identifies the top-requesting IP address per country for each 5-minute window. Seeing regional traffic patterns allows you to detect suspicious activity from specific geographies or apply geo-based rate limits. Azure Front Door: AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestCount = count() by bin(TimeGenerated, 5m), clientCountry_s, clientIp_s | summarize arg_max(RequestCount, clientIp_s) by TimeGenerated, clientCountry_s | project TimeGenerated, clientCountry_s, clientIp_s, RequestCount | order by TimeGenerated asc, clientCountry_s asc Usage: Use this to justify stricter thresholds for high-traffic countries or create region-specific custom WAF rules. The screenshot below shows the output of the geo-based query, which identifies the most active IP address per country in 5-minute intervals. As observed, some IPs consistently generate higher request volumes than others, indicating regional traffic concentration or potential anomalies. This pattern can help inform geo-specific rate limiting strategies, where regions with higher activity may warrant stricter thresholds or additional monitoring to mitigate localized abuse without impacting global user experience. Query 4: Request trends per URI segment This query breaks down requests by the first segment of the URI path (e.g., /api, /assets). It helps identify which parts of your app are most accessed. Azure Front Door: AzureDiagnostics | where Category == "FrontDoorAccessLog" | extend Path = tostring(parse_url(requestUri_s).Path) | extend FirstSegment = extract("^/([^/]+)", 0, Path) | summarize RequestCount = count() by FirstSegment, bin(TimeGenerated, 5m) | order by TimeGenerated asc, RequestCount desc Usage: Endpoints such as /login or /register are often targets for abuse. Segment-level analysis helps you target rate limits to specific parts of your app. The screenshot below shows the request distribution across the first URI segment (or resource) in 5-minute intervals. From the data, it’s clear that certain endpoints such as those serving static files (e.g., /styles.css) or known paths like /favicon.ico have consistent but low traffic. However, there are sudden spikes, such as 27 requests to /styles.css and 56 requests to /checkout.html, which could indicate automation, scraping, or testing behavior. Tracking usage by URI segment helps you identify which parts of your app are under heavy or suspicious load. You can use this insight to apply URI-specific rate limiting rules, especially for sensitive or high-traffic paths (e.g., /checkout, /login, /debug). This minimizes the risk of abuse without throttling static content or safe endpoints. Query 5: Average requests per full URI This query calculates the average number of requests per full URI across all 5-minute intervals. It helps identify high-traffic endpoints. Endpoints with consistently high traffic may need dedicated rate limits. Azure Front Door: AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestsPerUri = count() by requestUri_s, bin(TimeGenerated, 5m) | summarize AvgRequestsPerUri = avg(RequestsPerUri) by requestUri_s | order by AvgRequestsPerUri desc Usage: Use this to create path-specific rules; for example, /login may need a stricter threshold than /homepage. The screenshot below shows the results of the query, highlighting which full URIs receive the highest average number of requests over 5-minute intervals. The results show frequent access to specific assets (e.g., /favicon.ico, /styles.css), REST API endpoints, and one suspicious XSS injection attempt with unusually high traffic. This insight helps identify abuse patterns, automated scans, or popular resources, guiding you to apply rate limits more precisely either globally or per path to protect critical or vulnerable endpoints. Guidance and Considerations The KQL queries and thresholds shared in this blog are intended as guidance based on common patterns and demo environments. Traffic behavior varies across applications, and you should validate results against your own environment and adjust thresholds accordingly. Always test custom rules in Detection mode before enforcing them in Prevention mode to avoid disrupting legitimate traffic. It’s also important to consider the scalability of the application or backend service behind Azure Front Door. Rate limiting controls traffic, but if your app runs on a single instance or doesn’t scale well, it may still fail under load. As a best practice, ensure your services can auto scale or handle spikes gracefully in tandem with WAF rate limiting rules. Conclusion Configuring effective rate limiting in Azure Front Door WAF is not just about setting arbitrary thresholds. It requires understanding how your application is accessed and where traffic patterns indicate potential abuse or anomalies. By leveraging diagnostic logs and analyzing real-world traffic with KQL, you can create rate limit rules that are both protective and practical. This data-driven approach helps you to reduce noise, prevent misuse, and maintain a smooth experience for legitimate users. References What is Azure Web Application Firewall on Azure Front Door? | Microsoft Learn Web application firewall custom rule for Azure Front Door | Microsoft Learn Web application firewall rate limiting for Azure Front Door | Microsoft Learn Azure Web Application Firewall monitoring and logging | Microsoft LearnIntroducing the new Network Security Hub in Azure
Background: Since its launch in 2020, Azure Firewall Manager has supported customers in securing their networks. But the role of network security has since evolved, from a foundational requirement to a strategic priority for organizations. Today, organizations must protect every endpoint, server, and workload, as attackers continually search for the weakest link. Over the years, we’ve heard consistent feedback about the importance of centralized management, easier service discovery, and streamlined monitoring across their network security tools. These capabilities can make the difference between a minor incident and a major breach. That’s why we’re excited to introduce a new, unified Network Security hub experience. This updated hub brings together Azure Firewall, Web Application Firewall, and DDoS Protection—enabling you to manage, configure, and monitor all your network security services in one place. While Azure Firewall Manager offered some of this functionality, the name didn’t reflect the broader scope of protection and control that customers need. With this new experience, Firewall Manager has expanded into the Network Security Hub, making it easier to discover, configure, and monitor the right security services with just a few clicks. The result: less time navigating, more time securing your environment. What you’ll notice: Streamlined navigation: Whether you search for Azure Firewall, Web Application Firewall, DDoS Protection, or Firewall Manager, you’ll now be directed to the new Network Security hub. This unified entry point presents all relevant services in context—helping you stay focused and quickly find what you need, without feeling overwhelmed. Overview of services: The hub’s landing page provides a high-level view of each recommended solution, including key use cases, documentation links, and pricing details—so you can make informed decisions faster. Common scenarios: Explore typical deployment architectures and step-by-step guidance for getting started, right from the overview page. Related services: We’ve consolidated overlapping or closely related services to reduce noise and make your options clearer. The result? Fewer, more meaningful choices that are easier to evaluate and implement. New insights: We've enhanced the security coverage interface to show how many of your key resources are protected by Azure Firewall, DDoS Protection, and Web Application Firewall. Additionally, our integration with Azure Advisor now provides tailored recommendations to help you strengthen your security posture, reduce costs, and optimize Azure Firewall performance. What this means for you: No changes to Firewall Manager pricing or support: This is a user experience update only for Firewall Manager. You can continue to deploy Firewall policies and create Hub Virtual Network or Secured Virtual Hub deployments —now within the streamlined Network Security hub experience. Aligned marketing and documentation: We’ve updated our marketing pages and documentation to reflect this new experience, making it easier to find the right guidance and stay aligned with the latest best practices. Faster decision-making: With a clearer, more intuitive layout, it’s easier to discover the right service and act with confidence. Better product experience: This update brings greater cohesion to the Azure Networking portfolio, helping you get started quickly and unlock more value from day one Before: The original landing page was primarily focused on setting up Firewall Policies and Secured Virtual Hub, offering a limited view of Azure’s broader network security capabilities. After: The updated landing page delivers a more comprehensive and intuitive experience, with clear guidance on how to get started with each product—alongside common deployment scenarios to help you configure and operationalize your network security stack with ease. Before: The previous monitoring and security coverage experience was cluttered and difficult to navigate, making it harder to get a quick sense of your environment’s protection status. After: The updated Security Coverage view is cleaner and more intuitive. We've streamlined the layout and added Azure Advisor integration, so you can now quickly assess protection status across key services and receive actionable recommendations in one place. The expansion of Firewall Manager into the Network Security hub is part of a greater strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. You can learn more about this initiative in this blog. This shift is designed to better align with customer needs and industry best practices—by emphasizing core services, consolidating related offerings, and phasing out legacy experiences. The result is a more cohesive, intuitive, and efficient product experience across Azure Networking. 📣 If you have any thoughts or suggestions about the user interface, feel free to drop them in the feedback form available in the Network Security hub on the Azure Portal. Documentation links: Azure Networking hub page: Azure networking documentation | Microsoft Learn Scenario Hub pages: Azure load balancing and content delivery | Microsoft Learn Azure network foundation documentation | Microsoft Learn Azure hybrid connectivity documentation | Microsoft Learn Azure network security documentation | Microsoft Learn Scenario Overview pages What is load balancing and content delivery? | Microsoft Learn Azure Network Foundation Services Overview | Microsoft Learn What is hybrid connectivity? | Microsoft Learn What is Azure network security? | Microsoft Learn
Protect against SharePoint CVE-2025-53770 with Azure Web Application Firewall (WAF)
Summary Microsoft recently disclosed CVE-2025-53770, a critical vulnerability affecting on-premises SharePoint Server versions 2016, 2019, 2010, 2013, and Subscription Edition (SE). The vulnerability allows unauthenticated remote code execution (RCE) by chaining two separate CVEs: CVE-2025-49706 – Authentication Bypass CVE-2025-49704 – Deserialization Vulnerability Microsoft has released security updates for SharePoint Server 2016, 2019, and SE. Versions 2010 and 2013 are out of support and will not receive patches, leaving them exposed. If exploited, this vulnerability could allow an attacker to bypass authentication, extract cryptographic keys, and execute arbitrary C# code on the server. Technical details On-premises SharePoint Servers are enterprise-grade collaboration platforms that organizations install and manage on their own infrastructure, typically in their data centers. The attack chain for CVE-2025-53770 involves the following steps: CVE-2025-49706 – Authentication Bypass The attacker sends a crafted POST request targeting the endpoint:/_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx with a malicious Referer value:/_layouts/SignOut.aspxThis manipulates SharePoint into trusting the request and its payload. CVE-2025-49704 – Deserialization Vulnerability The attacker then sends a POST request with a serialized spinstall0.aspx payload, designed to extract MachineKey values from web.config. These keys are then used to craft a serialized C# code payload embedded in a valid __VIEWSTATE, which SharePoint trusts and executes. Microsoft guidance We strongly recommend following Microsoft's official mitigation steps outlined in the MSRC blog: Customer guidance for SharePoint vulnerability CVE-2025-53770 | Microsoft Security Response Center See the “How to protect your environment” section for patching guidance, configuration updates, and additional mitigation strategies. Protecting with Azure Web Application Firewall You can create a custom rule to help detect and block suspicious requests matching known indicators of this attack. Example WAF custom rule: Condition 1: URI contains / _layouts/15/ToolPane.aspx or / _layouts/15/spinstall0.aspx Condition 2: Referer header contains / _layouts/SignOut.aspx or / _layouts/15/SignOut.aspx JSON view "customRules": [ { "name": "CVE202553770", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestUri" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "(?i)/_layouts(?:/\\d+)?/(SignOut|spinstall0|ToolPane)\\.aspx" ], "transforms": [] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Referer" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "(?i)/_layouts(?:/\\d+)?/(SignOut|spinstall0|ToolPane)\\.aspx" ], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" } ] Next steps Patch immediately: Apply Microsoft’s updates for SharePoint 2016, 2019, and SE. Isolate legacy systems: SharePoint 2010 and 2013 remain vulnerable—consider restricting network access or migrating to supported versions. Deploy WAF protections: Add the custom rule above to monitor and block suspicious traffic targeting vulnerable endpoints. You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here. For more on Azure WAF, see: Azure Web Application Firewall documentation
