Protect against React RSC CVE-2025-55182 with Azure Web Application Firewall (WAF)
Please subscribe to this blog as we will be updating the suggested rules as new attack permutations are found. On December 3, 2025, the React team disclosed a critical remote code execution (RCE) vulnerability in React Server Components (RSC), tracked as CVE-2025-55182. The vulnerability allows an unauthenticated attacker to send a specially crafted request to an RSC “Server Function” endpoint and potentially execute arbitrary code on the server. This vulnerability affects applications using React RSC in the following versions: 19.0.0 19.1.0 19.1.1 19.2.0 Patched versions are available, and all customers are strongly encouraged to update immediately. About CVE-2025-55182 According to the React security advisory, the issue stems from unsafe deserialization within React Server Components, where server function payloads were not adequately validated. When exploited, an attacker can execute arbitrary code on the server without authentication. The NVD entry classifies this vulnerability as Critical, with a CVSS score of 10.0, due to its ease of exploitation and the potential impact on server-side execution. All organizations using React Server Components — or frameworks that embed RSC capabilities such as Next.js, React Router (RSC mode), Waku, @parcel/rsc, @vitejs/plugin-rsc, or rwsdk — should consider themselves potentially exposed until the relevant patches are applied. Azure WAF Mitigation to CVE-2025-55182 The primary and most effective mitigation for this vulnerability is to upgrade any unpatched React versions to the latest security-patched releases. Mitigation on WAF on Application Gateway or Application Gateway for Containers If you are using the latest and recommended ruleset Default Rule Set (DRS) 2.1, a new CVE-specific rule has been added to Azure WAF on Application Gateway and Application Gateway for Containers. Ensure that this rule remains enabled and retains its default Anomaly Score action. Rule ID: 99001018 Rule Description: Attempted React2Shell remote code execution exploitation (CVE-2025-55182) If you are using an older ruleset version such as CRS 3.2, CRS 3.1, or CRS 3.0, it is strongly recommended to upgrade to DRS 2.1. If upgrading is not currently possible, you can create custom WAF rules to detect this exploit pattern. These custom rules are configured with a Block action. We recommend validating them in a test or staging environment before enforcing them in production. Custom rules definition for WAF on Application Gateway and Application Gateway for Containers: "customRules": [ { "name": "cve202555182", "priority": 1, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "next-action" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" }, { "name": "cve202555182ver2", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "rsc-action-id" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" } ], If your Azure WAF is configured with an older ruleset version, such as CRS 2.2.9, CRS 3.0, or CRS 3.1, adding these custom rules may fail if your WAF runs on the old WAF engine. In this case, we strongly recommend upgrading your WAF policy to the next-generation WAF engine by moving to a newer ruleset: either to the latest DRS 2.1 which includes the built-in managed rule (preferred) or to the previous CRS 3.2, then apply the custom rules described above. If upgrading your ruleset version is not an option, and your WAF remains on the old WAF engine, you can instead use the following alternative rules: "CustomRules": [ { "Name": "cve202555182", "Priority": 1, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "Transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "next-action" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" }, { "Name": "cve202555182ver2", "Priority": 2, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "ATransforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "rsc-action-id" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" } ] Mitigation for WAF on Azure Front Door: If you are using WAF on Azure Front Door, you can create custom WAF rules to detect this exploit pattern. These custom rules are configured with a Block action. We recommend validating them in a test or staging environment before enforcing them in production. "customRules": [ { "name": "cve202555182", "enabledState": "Enabled", "priority": 1, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "next-action", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] }, { "name": "cve202555182ver2", "enabledState": "Enabled", "priority": 2, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "rsc-action-id", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] } ] You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here. Changelog 12/20/2025 11:00 PST - Updated built-in managed rule on WAF for Application Gateway and Application Gateway for Containers 12/7/2025 23:30 PST - Updated custom rules to detect additional attack permutation 12/5/2025 17:45 PST - Updated custom rules to include additional transform "RemoveNulls".
Application layer DDoS protection using the HTTP DDoS Ruleset in Azure WAF
Today, Distributed Denial of Service (DDoS) attacks can strike as soon as public connectivity is enabled, highlighting their widespread prevalence. Factors such as easily accessible botnets, the explosion of IoT devices, and the growth of API-driven workloads, e-commerce platforms, and global web applications have made these attacks easier to launch and more impactful. Importantly, attackers are no longer focusing solely on the network layer, they increasingly target the application layer. Application-layer DDoS attacks often mimic normal user activity, making detection and mitigation far more challenging than traditional network-layer attacks. The most common types of Application layer/HTTP based DDOS attacks are outlined below. Common HTTP-based DDoS attacks: HTTP floods: Large volumes of valid looking GET or POST requests are sent to webpages or APIs, overwhelming application gateways and backend services without saturating network bandwidth. API abuse attacks: Attackers repeatedly call specific API endpoints, such as authentication, search, or checkout that trigger expensive backend operations, quickly exhausting compute and database resources. Slow HTTP attacks: Connections are deliberately kept open by sending data very slowly, consuming server threads and connection limits while generating relatively little traffic. TLS-intensive attacks: A high number of encrypted connections are initiated to increase CPU usage during TLS handshakes, impacting application gateways and load balancers. In order to defend against these sophisticated threats, organizations need application-aware protection that can identify abnormal behavior patterns rather than relying only on traffic volume. This is precisely the capability provided by the HTTP DDoS Ruleset for Azure Application Gateway WAF. What Is the HTTP DDoS Ruleset? The HTTP DDoS Ruleset is a built-in capability of Azure Application Gateway WAF designed to protect your applications from large-scale HTTP floods at the application layer. Unlike static rate-limiting or manual IP blocking, this ruleset uses adaptive learning to understand what “normal” traffic looks like for your gateway and then automatically mitigates anomalies. Key features Baseline learning: The ruleset observes traffic for about 24 hours to establish a normal request pattern per gateway. Dynamic detection: When incoming requests exceed the learned baseline, the ruleset identifies potential abuse (Client-specific or IP specific limits are applied only when the overall request volume to the gateway exceeds its learned baseline). Automated mitigation: Offending clients are blocked and are placed in a “penalty box” for the defined time (15 minutes). Sensitivity levels: Choose low, medium, or high to control aggressiveness. Medium is recommended for most workloads. Leverages Microsoft’s vast global network’s threat intelligence to establish a stricter baseline for suspected botnet traffic and when exceeded, blocks them and places those suspected bots into the penalty box. Threat intelligence plays a critical role here. By continuously aggregating data from global telemetry, threat intelligence systems can identify sources that are likely participating in coordinated attacks. When applied to HTTP DDoS protection, this intelligence allows suspected bot traffic to be treated differently from normal user traffic. Instead of relying only on static blocklists, botnet-aware defenses use reputation, behavior, and historical signals to apply throttling or penalties dynamically. This approach reduces the attack surface, limits the impact of distributed bot-driven floods, and avoids unnecessary disruption to legitimate users. Threat intelligence shifts DDoS defense from a purely reactive posture to a more informed, proactive one, making it far more effective against today’s botnet-driven application-layer attacks. Enabling and validating the HTTP DDoS Ruleset: Getting started with the HTTP DDoS Ruleset on Application Gateway WAF is simple. Enable the Ruleset: In the Azure portal, open your WAF policy. Note: Currently the ruleset is available only in the preview portal: https://preview.portal.azure.com/ Under Managed Rules, Click on Assign and then assign the HTTP DDoS Ruleset_1.0 (Preview) and save. Each rule can be configured to either Log traffic for observation or Deny traffic for active mitigation. Sensitivity can be adjusted to High, Medium, or Low, allowing you to balance detection speed and accuracy. Higher sensitivity enforces lower thresholds and detects anomalies sooner, while lower sensitivity raises thresholds to reduce false positives. Medium sensitivity is the default and recommended setting for most workloads. Once enabled, the ruleset is evaluated early in the WAF pipeline, before custom rules are processed. This ensures that HTTP-based DDoS protection cannot be bypassed by DDoS protection. The ruleset works alongside the Default Rule Set (DRS) and any custom rules for comprehensive security. After the policy is applied to an Application Gateway, the ruleset enters a learning phase that lasts at least 24 hours. During this time, it observes traffic patterns to establish normal baselines for the gateway. No detection or blocking occurs during this period, allowing the ruleset to understand typical application behavior before enforcement begins. Metrics: Once the learning phase completes, traffic surges that exceed the learned baseline are reflected in the Application Gateway metrics. These metrics provide immediate visibility into when the HTTP DDoS ruleset is actively detecting and mitigating abnormal behavior. Metric – WAF Penalty Box Size This metric shows how many IP addresses are currently inside the penalty box, meaning that the WAF has detected them exceeding the learned HTTP DDoS baseline and is temporarily blocking them. A spike here indicates that multiple clients crossed their thresholds at the same time, often during an attack or load-test scenario. Metric – WAF Penalty Box Hits This metric represents how many IPs entered the penalty box. Every time a client breaches its threshold, the ruleset logs a hit and places that IP into the penalty box for approximately 15 minutes. Multiple hits often correlate with repeated spikes or sustained abusive traffic patterns. Logs: For deeper analysis, enabling diagnostic settings allows you to inspect HTTP DDoS Ruleset events directly in the logs. These logs provide granular details about which IPs were flagged, why they were flagged, and how far they exceeded expected thresholds. Example of DetailedData from a log: RemoteAddress: 4.x.x.x (Public IP) crossed threshold. Expected: 4400.000000 request per 900 seconds, Actual: 8407.000000 requests per 900 seconds. KQL queries to retrieve these logs: Resource specific logs: AGWFirewallLogs | where RuleSetType == "Microsoft_HTTPDDoSRuleSet" Diagnostic logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | where ruleSetType_s == "Microsoft_HTTPDDoSRuleSet" Note: Identify IPs repeatedly flagged and confirm they’re malicious, not legitimate clients. Conclusion: The threat landscape continues to evolve, and defenses must evolve with it. Leveraging the HTTP DDoS Ruleset in Azure Application Gateway WAF helps ensure protections keep pace with modern application-layer attacks. With built-in visibility through metrics and logs, teams can better understand traffic behavior and operate their WAF with greater confidence. Next Steps: Access the HTTP DDoS ruleset for Application Gateway via the preview portal: https://preview.portal.azure.com/ HTTP DDoS Ruleset (Preview) - Application Gateway WAF | Microsoft Learn Azure Web Application Firewall (WAF) policy overview | 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-hubGeneral 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 LearnMonitoring 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 Learn
