WAF custom rule for bock others cookie and permit only a specific cookie name and value
Hello all, I need to create a custom WAF rule that only allows traffic for a specific request URI (/example-path) if it contains a particular cookie, Cookie=abc123, and blocks all other requests. Additionally, could someone clarify the difference between configuring the policy this way: RequestHeaders['Cookie'], Operator=DoesNotEqual, Values="Cookie=abc123" RequestCookie, Values="CookieName", Operator=Equal, valueOfTheCookie="abc123" I hope I explained myself clearly. Thanks in advance for your responses!
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 Default Rule Set (DRS) 2.1, or the previous Core Rule Set (CRS) 3.2, a new CVE-specific managed rule is available in Azure Web Application Firewall (WAF) for Application Gateway and Application Gateway for Containers. Please ensure this rule is enabled and retains its default Anomaly Score–based action: Rule ID: 99001018 (DRS 2.1) or 800115 (CRS 3.2) Rule description: Attempted React2Shell remote code execution exploitation (CVE-2025-55182) This CVE-specific rule has also been added to CRS 3.1. However, for enhanced and more comprehensive protection specifically against CVE-2025-55182, we strongly recommend upgrading to DRS 2.1, which includes additional detection coverage and tuning for this vulnerability. If you are using CRS 3.0, there is no built-in CVE-specific protection for CVE-2025-55182, and upgrading to DRS 2.1 is strongly advised. If upgrading is not currently possible, you may implement custom WAF rules to detect this exploit pattern using a Block action. Any custom rules should be validated in a test or staging environment before being enforced 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" } ], 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 1/19/2026 5:00 PST - Updated built-in managed rule for CRS 3.2 and CRS 3.1 on WAF for Application Gateway 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".How 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-hubPublic 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 WAFAzure Application Gateway protection against CVE-2025-8671 (MadeYouReset)
A new HTTP/2 vulnerability, CVE-2025-8671 (MadeYouReset), was recently disclosed on August 13, 2025. This attack leverages carefully crafted protocol frames to force servers into repeatedly resetting streams on a single connection, which can lead to high resource consumption and denial of service (DoS) in extreme cases. MadeYouReset and Rapid Reset (CVE-2023-44487) are two similar attack patterns exploiting HTTP/2 steam resets feature leading to resource exhaustion. Stronger Defense with Azure Application Gateway If you are using Azure Application Gateway, you are already protected against MadeYouReset vulnerability. Two years ago in 2023, when addressing the Rapid Reset (CVE-2023-44487) attack, our engineering team implemented a comprehensive mitigation for these streams reset types of attacks. We introduced stronger safeguards to account for all kinds of stream cancellation regardless of the reason to protect against different flavors of rapid reset attacks. Customer Impact These safeguards are already active in Azure Application Gateway. No customer action is required. Azure services remain secure and resilient against this new class of HTTP/2 protocol attacks.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
Securing Containerized Applications with Application Gateway for Containers and Azure WAF
Azure Application Gateway for Containers is a modern, Kubernetes-native Layer 7 load balancer designed to manage ingress traffic for containerized applications running in Azure Kubernetes Service (AKS). Application Gateway for Containers is the evolution of the Application Gateway Ingress Controller (AGIC), and introduces a new control and data plane architecture, enabling near-instant updates to routes, probes, and backend pods. It supports features like traffic splitting, mutual TLS, header-based routing and increased performance—making it ideal for microservices and multi-tenant environments. But what truly sets Application Gateway for Containers apart is its native integration with Azure Web Application Firewall (WAF). Application Gateway for Containers introduces a Kubernetes-native custom resource called WebApplicationFirewallPolicy, allowing WAF policies to be defined and scoped directly within the cluster. WAF acts as the first line of defense, inspecting all incoming traffic before it reaches your pods. WAF policies can be applied at the listener level or scoped down to specific routes, giving you precise control over how and where security is enforced. This flexibility allows security teams to deploy global protections (like the OWASP Top 10 rules for SQL injection and cross-site scripting protection) across services while also enabling developers to fine-tune route-level rules for sensitive endpoints, like /login, /upload, or /admin. Further, Azure WAF supports prevention and detection modes, enabling you to start with alert-only configurations before moving to full enforcement allowing you to fine tune the WAF for your environment. You can also write your own rules by using the Custom Rules option. Using custom rules, you can block, allow, or log traffic based on headers, IP addresses, query parameters, or geolocation—giving security teams precise control over how threats are mitigated. Let’s walk through how Azure WAF enhances security when integrated with Application Gateway for Containers. Bot mitigation: Azure WAF’s bot manager uses Microsoft threat intelligence to categorize and manage bot traffic—blocking known malicious bots, allowing verified good bots, and logging unknown ones by default. DRS 2.1: Provides robust coverage against common web vulnerabilities, including Path Traversal, Cross-Site Scripting (XSS), SQL Injection and other OWASP Top 10 threats along with MSTIC (Microsoft Threat Intelligence Collection) rules. Custom rules: You can block requests with suspicious user-agent headers, rate-limit traffic to prevent abuse, geo-block traffic from regions you don’t serve, apply header inspection, IP filtering, and more Real-time observability: With Application Gateway for Containers, WAF logs and metrics are integrated into your observability stack. You can correlate WAF blocks with transaction IDs, trace attack vectors end-to-end, and validate that legitimate users remain unaffected. Let’s take a look at how you can achieve these benefits using WAF for Application Gateway for Containers: Deploying WAF and defining WAF policies in Kubernetes: Please make sure you have the following resources set up before getting started: Azure Kubernetes Service (AKS) – Ensure your backend application is deployed and running in AKS. Application Gateway for Containers – Deploy Application Gateway for Containers to manage ingress traffic to your containerized workloads. WAF Policy – Create a new WAF policy or reuse an existing one already configured for Application Gateway. Attach the WAF Policy – Attach the WAF policy with a new security policy under the Application Gateway for Containers settings as shown below. Note: Security policies act as the bridge between your Azure WAF policy and the Kubernetes-native routing resources (like Gateway or HTTP Route). Without this association, the WAF policy exists in Azure but isn’t enforced on your containerized traffic. In this example, we have setup a backend application in AKS. The setup includes: A namespace called test-infra Two services called backend-v1 and backend-v2 Two deployments called backend-v1 and backend-v2 You’ll also create: A Gateway named gateway-01 Two HTTP Routes: http-route1 for path /bar and /some/thing http-route2 for path /anything Defining WAF policies As mentioned earlier, Application Gateway for Containers introduces a new Kubernetes custom resource called WebApplicationFirewallPolicy which allows you to define and scope Azure WAF policies directly within your AKS cluster. The following scopes may be defined: Gateway (global) HTTP Route (granular) Note: These are not mutually exclusive, you can apply both a gateway-level policy and per-route policies, and the route-level policy takes precedence over the gateway-level one. Here is an example WebApplicationFirewallPolicy YAML file: apiVersion: alb.networking.azure.io/v1 kind: WebApplicationFirewallPolicy metadata: name: sample-waf-policy namespace: test-infra spec: targetRef: group: gateway.networking.k8s.io kind: HTTPRoute name: http-route2 namespace: test-infra sectionNames: ["pathA"] webApplicationFirewall: id: /subscriptions/.../Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/waf-policy-0 Note: The name field here should match the HTTP route name so it can be applied to the appropriate HTTP route when there are multiple of them. Applying the policy: To apply the policy in AKS: kubectl apply -f waf.yaml To verify it was applied correctly: kubectl get webapplicationfirewallpolicy.alb.networking.azure.io -A -o yaml The output should look like this- apiVersion: alb.networking.azure.io/v1 kind: WebApplicationFirewallPolicy metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"alb.networking.azure.io/v1","kind":"WebApplicationFirewallPolicy","metadata":{"annotations":{},"name":"sample-waf-policy","namespace":"test-infra"},"spec":{"targetRef":{"group":"gateway.networking.k8s.io","kind":"HTTPRoute2","name":"http-route","namespace":"test-infra"},"webApplicationFirewall":{"id":"/subscriptions/{Subscription Name}/resourceGroups/{Resource Group Name}/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/{WAF Name}"}}} creationTimestamp: "2025-07-17T04:50:30Z" generation: 7 name: sample-waf-policy namespace: test-infra resourceVersion: "175009" uid: 031b6b5a-96c8-4d9f-8cc0-9d5e00000 spec: targetRef: group: gateway.networking.k8s.io kind: HTTPRoute name: http-route2 namespace: test-infra webApplicationFirewall: id: /subscriptions/{Subscription Name}/resourceGroups/{Resource Group Name}/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/{WAF Name} status: conditions: - lastTransitionTime: "2025-07-17T05:33:39Z" message: Valid WebApplicationFirewallPolicy observedGeneration: 7 reason: Accepted status: "True" type: Accepted kind: List metadata: resourceVersion: "" This confirms that the WAF policy has been applied correctly to the right HTTP Route as shown here - name: http-route2 In this scenario, we’ve configured two WAF policies: WAF Policy 1: Associated with http-route1, using DRS 2.1 in Prevention Mode. WAF Policy 2: Associated with http-route2, using a custom geo-blocking rule to deny US based traffic and is in Prevention Mode. Testing WAF behavior: In this scenario, we attempt to access the frontend URL specifically the path “/some/thing” which has the WAF Policy1 associated to it. To test the policy’s effectiveness, we simulate a SQL injection attack targeting this path as seen below. The response below demonstrates the WAF engine detecting and blocking the malicious request with an “Access Forbidden” response: In the next test scenario, when a request is sent from a US-based IP address to the path /anything, we get a 403 Forbidden message. This is because WAF Policy 2 is configured with a custom geo-blocking rule to block traffic from the US region using the Client IP address. It detects the origin and blocks the request. As a result, the client receives an “Access Forbidden” response, confirming that the policy is actively enforcing geographic restrictions. However, when accessing other paths such as /bar or /some/thing, the request is not blocked. This is because those paths are handled by a different route (http-route1) that is associated with WAF Policy 1, which does not include geo-blocking rules. This behavior highlights how WAF policy scoping allows you to apply different security rules to different parts of your application, enabling fine-grained control over traffic protection. Note: If a specific path does not have a WAF Rule associated with it, it inherits the WAF Policy that is applied at the Global level Monitoring: While Azure WAF protects the Application Gateway for Containers, having deep visibility into traffic and threat patterns is essential for maintaining a secure and resilient application environment. To do that, we will enable diagnostic logging on the Application Gateway for Containers as shown below: Once the traffic triggers a WAF rule due to an identified attack or custom rule, you will see WAF related logs using the query- “AGCFirewallLogs”. As seen, the logs provide detailed information related to the attacks such as the WAF policy that is being applied, the scope at which it is being applied, the RequestUri, RulesetType and much more. Azure WAF also supports sensitive data scrubbing. For example, you can redact fields like the request IP address in the logs to maintain privacy while still capturing actionable intelligence as shown below: As seen here, by integrating WAF logs and metrics into your observability stack, you gain real-time insights into blocked threats, user behavior, and application performance. This enables teams to trace incidents end-to-end, validate WAF effectiveness, and fine-tune policies with confidence. Whether you're investigating a blocked request or correlating alerts with backend performance, Log Analytics empowers you to move from detection to diagnosis seamlessly. Conclusion: Azure Application Gateway for Containers paired with Web Application Firewall (WAF) offers a powerful, flexible, and Kubernetes-native approach to securing microservices at the edge. By enabling WAF policies at both the listener and route levels, teams can enforce broad protections while tailoring defenses for high-risk endpoints. Whether you're mitigating bots, blocking injection attacks, or applying geo-based restrictions, Application Gateway for Containers with WAF empowers you to shift security left—closer to where your services live and evolve. Start with detection, move to prevention, and scale with confidence. Next steps What is Application Gateway for Containers? | Microsoft Learn Web Application Firewall on Application Gateway for Containers | Microsoft Learn Default rule set 2.1 - Azure Web Application Firewall WAF on Azure Application Gateway bot protection overview | Microsoft Learn Azure Web Application Firewall (WAF) v2 custom rules on Application Gateway | Microsoft LearnAzure WAF Tuning for Entra External ID
Introduction This blog is the second part of a series on tuning Azure Web Application Firewall (WAF) for Entra External ID/Azure Active Directory (AD) and serves as a follow-up to the earlier blog on Azure WAF Tuning with AD B2C Applications. With the introduction of Microsoft Entra External ID in 2024, some customers may experience similar challenges to those faced with Azure AD B2C, particularly around false positives generated by Azure WAF. This blog aims to provide guidance on how to best tune Azure WAF to handle traffic from Entra External ID, ensuring a seamless and secure experience for your users. Difference between Azure AD B2C and Entra External ID Microsoft Entra External ID is an identity platform that lets organizations manage external users securely while offering greater flexibility and scalability. It streamlines the integration of external identities with applications, delivers a seamless sign-in experience, and provides advanced security and compliance features for both B2C and B2B scenarios. Azure AD B2C was designed for customer-facing applications, providing features such as social identity providers, custom branding, and self-service password reset. While it served many use cases effectively, Microsoft has since introduced Entra External ID as a more advanced and unified solution for both consumer-oriented app developers and businesses seeking secure B2B collaboration. Entra External ID includes enhanced security, compliance, and scalability features, making it a comprehensive solution for managing external identities. Note: Effective May 1, 2025, Azure AD B2C is no longer available to purchase for new customers. Microsoft is transitioning all new external identity scenarios to Microsoft Entra External ID. Existing Azure AD B2C tenants will continue to be supported until at least 2030. Please refer to Azure AD B2C end of sale. Understanding the Challenge Similar to Azure AD B2C, Microsoft Entra External ID uses OAuth/OpenID Connect flows. During sign-in, parameters such as code, and id_token can contain base64-encoded strings that appear suspicious to WAF’s Managed Rule Sets. Some of the commonly triggered rules belong to paranoia level 2 (PL2) rules, a more aggressive paranoia level that may trigger blocks (see the section on paranoia levels later in this post). The two PL2 rules we encounter most are: 942430 - This rule checks for a high number of special characters in request data indicating a possible SQL injection attempt. This rule is disabled by default in DRS 2.1. 942440 – This rule detects sequences in request data that resemble SQL comments which are often used in SQL injection attacks. This rule is disabled by default in DRS 2.1 (Azure Front Door WAF) and is replaced by the Microsoft Threat Intelligence Center (MSTIC) rule 99031002. In Application Gateway WAF, users can manually disable it. These rules often flag tokens or code parameters as potential SQL injection attempts because they detect certain characters and patterns in the tokens. Learn more about Azure WAF rulesets. Tuning Azure WAF for Entra External ID In this blog, we’ll demonstrate the tuning process using: Microsoft Entra External ID Tenant – configured for external-facing authentication. Static Web App (SWA) – front-end code with ‘.auth login’ using Microsoft Entra ID, allowing flexibility to create a custom application. Azure Front Door Premium with a WAF Policy – running DRS 2.1 managed rules. Custom Domain – ensures all traffic, including OAuth callbacks, flows via Azure Front Door with WAF. We begin by registering our static web app to Entra external ID. In our Microsoft Entra Admin center, we navigate to Identity > Applications > App registrations. We select ‘New registration’ and fill in the details for our static web app as below: Once registered, we proceed to grant authentication and finally grant admin consent. To learn more about registering an application in Entra ID refer to How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn. Once we verify authentication to our static web app, we configure Azure Front Door with WAF to protect the web app. Learn how to configure Azure Front Door with WAF by following this tutorial. We have configured our Static Web App to be accessed through an Azure Front Door endpoint (with WAF), ensuring all authentication requests also flow through WAF for inspection and protection. To achieve this, we use a custom domain so that the OAuth callbacks and user traffic are routed exclusively through the Azure Front Door rather than the default - .azurestaticapps.net domain. Please refer to Add a custom domain to Azure Front Door | Microsoft Learn to learn more about Azure Front Door custom domains. Resolving False Positives When your WAF policy is running in prevention mode, genuine user authentication requests might sometimes be blocked - this is called a false positive. When a false positive occurs, a user successfully authenticates, but they see a block page (example below) instead of the static web app. However, you might notice that sometimes the very same sign-in flow completes successfully with no block at all. This seemingly “inconsistent” behavior arises because WAFs running the Default Rule Set (DRS) 2.x uses anomaly scoring. In Anomaly scoring each triggered rule contributes a severity-based score: Notice (2), Warning (3), Error (4), and Critical (5). If the total anomaly score exceeds the threshold of 5, the request is blocked, otherwise it is allowed. Since OAuth tokens (such as code or id_token) change with each login attempt, they may sometimes trigger enough rules to reach this threshold – resulting in a block. To address this challenge, we take the following steps: Evaluate the WAF Logs Remediate with: Exclusions Custom rules Change the rule actions Disable rules Evaluate paranoia levels Evaluating the WAF Logs Understanding the logs generated by the WAF is critical to diagnosing and resolving these issues. It is recommended to initially run the WAF policy in detection mode to log traffic without blocking requests, allowing you to identify and fine-tune exclusions before enabling prevention mode. Once you have reviewed the logs and adjusted configurations as needed, you can switch to prevention mode to actively block malicious requests. In our setup, we evaluate the WAF behavior directly in prevention mode to observe real-time blocks and evaluate which rules were triggered. You can use the following KQL query in your Log Analytics Workspace to identify blocked requests: AzureDiagnostics | where ResourceProvider == "MICROSOFT.CDN" and Category == "FrontDoorWebApplicationFirewallLog" | where action_s == "Block" We observe several requests that were blocked: Each WAF log entry provides a tracking reference which is a unique identifier assigned to each WAF event to make it easier to correlate and trace specific requests across different logs. You can use this reference to correlate WAF events with application logs or client-side tracing tools. This is especially helpful in complex authentication flows involving multiple redirects as the tracking reference can pinpoint exactly which request in the chain was blocked. Using the tracking reference from our first log, we can identify the specific rules whose score added up for the block: We can identify that rules 942430 and 942440—both of which target SQL injection signatures—are contributing to the anomaly score and ultimately causing the block. These rules belong to the Default Rule Set (DRS) 2.x and are designed to detect common SQL injection attempts by scanning for suspicious tokens, special characters, or query-like substrings. Both 942430 and 942440 reside in the OWASP ModSecurity Core Rule Set (CRS) family, which specifically targets SQL injection attempts by looking for patterns often used in malicious queries. In the official CRS documentation, these rules focus on suspicious characters (e.g., ‘, -, ;), SQL keywords (SELECT, UNION), and encoded strings. More specifically: Rule 942430 – “Restricted SQL Character Anomaly Detection” - This rule counts the number of special characters (like =, +, ', etc.) within request parameters. If it detects too many in a single payload (for example, “# of special characters exceeded (12)”), it flags the request as highly suspicious. OAuth tokens, being base64-encoded, can contain =, +, and other symbols that push this count over the threshold, triggering a false positive. Rule 942440 – “SQL Comment Sequence Detected” - This rule looks for typical SQL comment patterns such as -- or #. If it detects any substring resembling a comment sequence—possibly even certain base64 fragments—it interprets the request as a potential SQL injection. Because Entra External ID tokens are randomized, they may occasionally contain partial sequences that match the rule’s detection logic, again leading to false positives. For more details on the specific rule IDs and their matching criteria, see the OWASP ModSecurity Core Rule Set (CRS) documentation, or the Azure WAF rule reference for Managed Rule Sets. Understanding the purpose and scope of these rules helps you decide how to best tune WAF—whether by using exclusions, custom rules, or other remediation methods—to accommodate legitimate Entra External ID tokens without compromising your application’s overall security. Remediation Options Exclusions Exclusions tell the WAF to bypass certain parameters, cookies, or headers for specified rules. This is often the safest approach when you trust specific values—such as the id_token and code parameters from Microsoft Entra ID. By removing these from inspection, you prevent them from contributing to the anomaly score. In the Azure portal, you can configure exclusions under your WAF policy’s Managed Rule Set settings, matching the relevant parameter name (e.g., code) to a specific location (like Request Body or QueryParam). Learn more about WAF exclusion lists in Azure Front Door and how to configure exclusion lists for Azure Front Door. In our own environment, we determined that rule 942430 often triggered on the code parameter, while rule 942440 flagged the id_token parameter—both located in the request body. To address this in a granular way, we created exclusion lists so that 942430 ignores code in the request body and 942440 ignores id_token in the request body. This ensures that WAF still inspects all other fields and traffic for malicious patterns, but no longer incorrectly penalizes these legitimate Entra External ID tokens. Below are screenshots illustrating these exclusions in action: Excluding in_code Parameter from SQL Comment Sequence Detection: Excluding code Parameter from SQL Comment Sequence Detection: Custom Rules Custom rules give you finer control over how the WAF handles requests - beyond what you can configure with exclusions or default managed rules. You can allow or block specific traffic patterns based on conditions such as request path, HTTP method, header contents, or query parameters. For a straightforward scenario, you might match the path /.auth/login/aad/callback (or whichever callback path your app uses), set the Action to Allow, and give the custom rule a lower priority so it’s evaluated first. This ensures legitimate Entra External ID traffic bypasses the SQL injection checks. If your tokens or parameters follow a partially predictable pattern (for instance, a certain prefix or structure in the base 64-encoded string), you can use regex matching in your custom rule to be more selective. For example, you might match the request parameter code with a regex like ^[A-Za-z0-9_-]+(\.[A-Za-z0-9_-]+)*$, which loosely allows base 64 token formats. This approach is handy if you notice tokens often trigger a variety of sub-rules. By allowing only the known safe format you drastically cut false positives while still blocking anything that strays from the legitimate pattern. Whether you’re using simple path matches or advanced regex, carefully scope your conditions—limit them to the specific parameters or paths you know are safe. A broad “Allow everything that includes ‘callback’” could inadvertently open a hole for real attacks. Change Rule Actions In some cases, you may prefer to keep the relevant rule enabled but change its action from Block to Log. This ensures that even if the rule matches, the request isn’t automatically blocked—rather, it’s logged for further investigation. If you later identify genuine threats in these tokens, you can revert to a stricter rule action or add more precise exclusions. Disable Specific Rules In some cases, you may decide that certain rules (for example, those repeatedly generating false positives but offering little relevant protection for your application) should be disabled entirely. This approach is generally a last resort because it removes that protective layer for all traffic rather than targeting just the problematic parameters. However, in our scenario, the two problematic rules - 942430 (Restricted SQL Character Anomaly Detection) and 942440 (SQL Comment Sequence Detected) - are disabled or replaced by default in DRS 2.1. If you’re seeing them trigger, you may be on an older rule set or a configuration where they remain active. Disabling them manually in the Managed Rule Set will stop the false positives, but you should monitor your WAF logs closely for genuine attacks that might have otherwise been caught by those rules. Where possible, consider upgrading to the latest rule set which often addresses these issues by default. Evaluate the Paranoia Levels Paranoia levels (PL) determine how aggressively rules in the OWASP Core Rule Set (CRS) detect and block potential threats in a Web Application Firewall (WAF). OWASP CRS defines four paranoia levels (PL1–PL4), each offering progressively stricter security controls: PL1 (Default): Offers baseline protection against common web attacks, minimizes false positives, and is appropriate for most applications. PL2: Adds additional rules targeting more sophisticated threats, which may result in more false positives. PL3: Provides stricter rules suitable for applications requiring high security, though these typically require extensive tuning. PL4: Implements the most aggressive security rules, suitable for highly secure environments, requiring extensive management and tuning efforts. For more detailed explanations of each paranoia level, refer to the OWASP CRS Paranoia Levels documentation. The Azure WAF managed rulesets - DRS 2.1 and CRS 3.2 – each contain rules with an assigned paranoia level. By default, these rulesets contain rules that include paranoia levels 1 and 2 (PL1 and PL2). To reduce false positives, you can either disable specific PL2 rules or set their action to 'log' instead of blocking. Azure WAF currently does not support rules from paranoia levels 3 and 4. For more information on Azure WAF paranoia levels refer to Azure Front Door WAF paranoia levels. In our scenario, rules 942430 and 942440 are classified under PL2 and carry a default anomaly score of 5. Triggering either rule individually exceeds the anomaly scoring threshold, causing legitimate authentication requests - such as those from OAuth/OpenID Connect flows used by Entra External ID - to be inadvertently blocked. To manage and reduce these false positives effectively: Initially configure your Azure WAF policy to use only PL1 rules to significantly lower the likelihood of false positives. Review and selectively re-enable necessary PL2 rules after analyzing WAF logs, applying specific exclusions or custom rules as described in the remediation section. Conclusion Azure Web Application Firewall (WAF) provides robust protection against web threats. However, when integrating with Microsoft Entra External ID for authentication, careful tuning is essential to avoid false positives that disrupt legitimate user access. By reviewing WAF logs, creating precise exclusions, implementing targeted custom rules, and leveraging the latest managed rule sets, organizations can optimize their security posture while ensuring smooth authentication experiences. Proper WAF tuning maintains a crucial balance between application security and user experience References Configure Microsoft Entra External ID with Azure Web Application Firewall - Microsoft Entra External ID | Microsoft Learn Tune Azure Web Application Firewall for Azure Front Door | Microsoft Learn Troubleshoot - Azure Web Application Firewall | Microsoft Learn Azure Web Application Firewall DRS rule groups and rules | Microsoft Learn Azure WAF tuning with AD B2C applications | Microsoft Community Hub
