Azure Networking Portfolio Consolidation
Overview Over the past decade, Azure Networking has expanded rapidly, bringing incredible tools and capabilities to help customers build, connect, and secure their cloud infrastructure. But we've also heard strong feedback: with over 40 different products, it hasn't always been easy to navigate and find the right solution. The complexity often led to confusion, slower onboarding, and missed capabilities. That's why we're excited to introduce a more focused, streamlined, and intuitive experience across Azure.com, the Azure portal, and our documentation pivoting around four core networking scenarios: Network foundations: Network foundations provide the core connectivity for your resources, using Virtual Network, Private Link, and DNS to build the foundation for your Azure network. Try it with this link: Network foundations Hybrid connectivity: Hybrid connectivity securely connects on-premises, private, and public cloud environments, enabling seamless integration, global availability, and end-to-end visibility, presenting major opportunities as organizations advance their cloud transformation. Try it with this link: Hybrid connectivity Load balancing and content delivery: Load balancing and content delivery helps you choose the right option to ensure your applications are fast, reliable, and tailored to your business needs. Try it with this link: Load balancing and content delivery Network security: Securing your environment is just as essential as building and connecting it. The Network Security hub brings together Azure Firewall, DDoS Protection, and Web Application Firewall (WAF) to provide a centralized, unified approach to cloud protection. With unified controls, it helps you manage security more efficiently and strengthen your security posture. Try it with this link: Network security This new structure makes it easier to discover the right networking services and get started with just a few clicks so you can focus more on building, and less on searching. What you’ll notice: Clearer starting points: Azure Networking is now organized around four core scenarios and twelve essential services, reflecting the most common customer needs. Additional services are presented within the context of these scenarios, helping you stay focused and find the right solution without feeling overwhelmed. Simplified choices: We’ve merged overlapping or closely related services to reduce redundancy. That means fewer, more meaningful options that are easier to evaluate and act on. Sunsetting outdated services: To reduce clutter and improve clarity, we’re sunsetting underused offerings such as white-label CDN services and China CDN. These capabilities have been rolled into newer, more robust services, so you can focus on what’s current and supported. What this means for you Faster decision-making: With clearer guidance and fewer overlapping products, it's easier to discover what you need and move forward confidently. More productive sales conversations: With this simplified approach, you’ll get more focused recommendations and less confusion among sellers. Better product experience: This update makes the Azure Networking portfolio more cohesive and consistent, helping you get started quickly, stay aligned with best practices, and unlock more value from day one. The portfolio consolidation initiative is a strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. By focusing on top-line services, combining related products, and retiring outdated offerings, Azure Networking aims to provide a more cohesive and efficient product experience. Azure.com Before: Our original Solution page on Azure.com was disorganized and static, displaying a small portion of services in no discernable order. After: The revised solution page is now dynamic, allowing customers to click deeper into each networking and network security category, displaying the top line services, simplifying the customer experience. Azure Portal Before: With over 40 networking services available, we know it can feel overwhelming to figure out what’s right for you and where to get started. After: To make it easier, we've introduced four streamlined networking hubs each built around a specific scenario to help you quickly identify the services that match your needs. Each offers an overview to set the stage, key services to help you get started, guidance to support decision-making, and a streamlined left-hand navigation for easy access to all services and features. Documentation For documentation, we looked at our current assets as well as created new assets that aligned with the changes in the portal experience. Like Azure.com, we found the old experiences were disorganized and not well aligned. We updated our assets to focus on our top-line networking services, and to call out the pillars. Our belief is these changes will allow our customers to more easily find the relevant and important information they need for their Azure infrastructure. Azure Network Hub Before the updates, we had a hub page organized around different categories and not well laid out. In the updated hub page, we provided relevant links for top-line services within all of the Azure networking scenarios, as well as a section linking to each scenario's hub page. Scenario Hub pages We added scenario hub pages for each of the scenarios. This provides our customers with a central hub for information about the top-line services for each scenario and how to get started. Also, we included common scenarios and use cases for each scenario, along with references for deeper learning across the Azure Architecture Center, Well Architected Framework, and Cloud Adoption Framework libraries. Scenario Overview articles We created new overview articles for each scenario. These articles were designed to provide customers with an introduction to the services included in each scenario, guidance on choosing the right solutions, and an introduction to the new portal experience. Here's the Load balancing and content delivery overview: Documentation links Azure Networking hub page: Azure networking documentation | Microsoft Learn Scenario Hub pages: Azure load balancing and content delivery | Microsoft Learn Azure network foundation documentation | Microsoft Learn Azure hybrid connectivity documentation | Microsoft Learn Azure network security documentation | Microsoft Learn Scenario Overview pages What is load balancing and content delivery? | Microsoft Learn Azure Network Foundation Services Overview | Microsoft Learn What is hybrid connectivity? | Microsoft Learn What is Azure network security? | Microsoft Lea Improving user experience is a journey and in coming months we plan to do more on this. Watch out for more blogs over the next few months for further improvements.
Azure Front Door 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 Front Door If you are using Azure Front Door, 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. Rather than limiting only client-initiated resets, 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 Front Door. 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
WordPress App how to restrict access to specific pages on the site
Hello all, I have a WordPress App hosted on Azure and I am struggling with how I can secure specific pages from public access. For example: http://www.mysite.com/wp-admin http://www.mysite.com/info.php I'd like it so that only specific IP addresses or Microsoft user accounts can access some, such as admin pages and for some pages I'd like no access at all, to where it just blocks any sort of visit. I've viewed the documentation for Front Door and some networking restrictions but that seems to be just IP addresses and I'm confused about how I can set those rule for specific pages within the App. I know WordPress offer plugins which have this sort of functionality but I'd like to take advantage of Azure's security features rather than plugins from WordPress. Any help is very appreciated. Thank youAzure 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
Accelerate designing, troubleshooting & securing your network with Gen-AI powered tools, now GA.
We are thrilled to announce the general availability of Azure Networking skills in Copilot, an extension of Copilot in Azure and Security Copilot designed to enhance cloud networking experience. Azure Networking Copilot is set to transform how organizations design, operate, and optimize their Azure Network by providing contextualized responses tailored to networking-specific scenarios and using your network topology.
Azure Front Door rules engine scenarios and configurations
*This post is a continuation of Azure Front Door's earlier blog on the topic. If you haven’t read it yet, you can find it: Revolutionizing hyperscale application delivery and security: The New Azure Front Door edge platform | Microsoft Community Hub The Azure Front Door rules engine allows users to easily customize processing and routing logic at the Front Door edge by configuring match condition and action pairs. You can define various rule actions based on combination of various supported match conditions from incoming requests. These rules allow you to: Manage cache policy dynamically Forward requests to different origins or versions Modify request or response headers to hide sensitive information or passthrough important information through headers. For example, implementing security headers to prevent browser-based vulnerabilities like: HTTP strict-transport-security (HSTS) X-XSS-protection Content-security-policy X-frame-options Access-Control-Allow-Origin headers for cross-origin resource sharing (CORS) scenarios. Security-based attributes can also be defined with cookies. Rewrite URL paths or redirect requests to new destinations Enable complex scenarios using regex and server variables: capture dynamic values from incoming requests or responses and combine them with static strings or other variables. This article covers common use cases supported by the rules engine, and how to configure these rules to meet your needs via Azure portal. You can find out Azure Resource Manager (ARM) template examples to help automate deployment of these capabilities in Azure Front Door rules engine scenarios. Scenario 1: Redirect using query string, URL path segments, or incoming hostname captures Managing redirects is critical for search engine optimization (SEO), user experience, and the proper functioning of a website. Azure Front Door's rules engine and server variables allow you to efficiently manage batch redirects based on various parameters. Redirect based on query string parameters You can redirect requests using query fields of the incoming URL by capturing the value of a specific query string key in the format {http_req_arg_<key>}. This approach enables dynamic redirects without having to create a separate rule for each cdpb value, significantly reducing the number of rules required. For example, extract the value of cdpb query key from an incoming URL: https://example.mydomain.com/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount and use it to configure the “destination host” into outgoing URL: https://teststorageaccount.blob.core.windows.net/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount. Redirect based on fixed-length URL path segments You can redirect requests to different origins based on fixed-length URL path segment by capturing the URL segments using {variable:offset:length}. For more information, see Server variable format. For example, consider a scenario where the tenant ID is embedded in the URL segment and is always six characters long, such as: https://api.contoso.com/{tenantId}/xyz. To extract {tenantId} from the URL and decide the correct redirect to use in the format of tenantId.backend.com/xyz. This approach eliminates the need to create a separate rule for each tenant ID, allowing you to handle dynamic routing with fewer rules. Redirect based on dynamic-length URL path segments When the URL path segment has a dynamic length, you can extract it using the {url_path:seg#}. For more information, see Server variable format. For example, if a tenant ID or location is embedded in the URL segment, such as: https://api.contoso.com/{tenantId}/xyz, you can extract {tenantId} from the URL and decide the correct redirect in the format of tenantId.backend.com/xyz with server variable {url_path:seg0}.backend.com in the redirect destination host. This method avoids creating separate rules for each tenant ID, enabling more efficient configuration. This can be configured via command line tools. Learn about how to configure for this rule via Azure Resource Manager (ARM) template in Azure Front Door rules engine scenarios. Redirect based on part of the incoming hostname You can redirect requests to different origins by extracting part of the incoming hostname. For example, you can capture tenantName from https://[tenantName].poc.contoso.com/GB to redirect the request to s1.example.com/Buyer/Main?realm=[tenantName]&examplename=example1 using the offset and length in server variable in the format of {hostname:0:-16}. For more information, see Server variable format. Scenario 2: Populate or modify a response header based on a request header value In some scenarios, you might need to populate or modify a response header based on a request header value. For example, you can add CORS header where needed to serve scripts on multiple origins from the same CDN domain, and response must contain the same FQDN in Access-Control-Allow-Origin header as the request origin header, rather than a wildcard allowing all domains (*) to enhance security. You can achieve it by using the {http_req_header_Origin} server variable to set the response header. Scenario 3: Rename a response header to a brand-specific one You can rename a response header generated by a cloud provider by adding a new custom response header and deleting the original. For example, you can replace the response header X-Azure-Backend-ID with a brand-specific header X-Contoso-Scale-ID. Scenario 4: A/B testing (experimentation) Splitting incoming traffic into two origin groups can be is useful in A/B testing, rolling deployments, or load balancing without complex backend logic. For example, you can split incoming traffic based on the client port number. A rule can match client ports that end in 1, 3, 5, 7, or 9 and forward those requests to an experiment-origin-group. All other traffic continues to the default origin group per route settings. The previous regex is just an example. You can explore and test your own expressions using tools like regex101. Note Since client ports are random, this method typically results in an approximate 50/50 traffic split. However, the presence of any proxies or load balancers between clients and the Front Door might affect this assumption due to factors like connection reuse or source port rewriting. Use logs or metrics to validate the actual behavior in your environment. Scenario 5: Redirect with URL path modification and preserve capability In some scenarios, you might need to add new segments or remove some segments while preserving the rest of the URL path. For example, if you want to redirect https://domain.com/seg0/seg1/seg2/seg3 to https://example.com/seg0/insert/seg2/seg3. In this scenario, you replace URL path’s {seg1} with /insert/ while preserving the rest of the URL path. Azure Front Door achieves the desired redirect by combining values extracted from server variables (URL segments) and combining static string segment /insert/. You can use Int32.Max (2147483647) for URL segment’s length field to keep all segments from seg2 to segn. For more information, see Server variable format. Note Similar configuration can be done for URL rewrite action by inputting source pattern as / and destination as /{url_path:seg0}/insert/{url_path:seg2:2147483647} for redirect action as shown in the following portal example. Scenario 6: Redirect by removing fixed parts of a URL path You can remove fixed segments of known size from a URL path, such as country codes (us) or locales (en-us), while preserving the rest of the URL path. For example, if you want to redirect https://domain.com/us/seg1/seg2/seg3/ to https://example.com/seg1/seg2/seg3/, you need to remove the country code /us/ and keep the rest of the URL path unchanged. To achieve this, use {variable:offset} , which includes the server variable after a specific offset, until the end of the variable. For more information, see Server variable format. Note Similar configuration can be done for URL rewrite action by inputting source pattern as / and destination as /“{url_path:3} for redirect action as shown in the following portal example. Scenario 7: URL rewrite by removing one or more segments of URL path You can remove one or more segments from a URL path, such as country codes (us) or locales (en-us), while preserving the rest of the URL path. For example, if you want to rewrite https://domain.com/us/seg1/seg2/seg3/ to https://origin.com/seg2/seg3/, you need to remove both the country code and an additional segment /us/seg1/ while keeping the rest of the URL path intact. To achieve this, use the {url_path:seg#:length} server variable format to capture specific URL segments starting from a particular segment number. In this example, use {url_path:seg2:2147483647} to capture all segments starting from seg2 to the end. The value 2147483647 (Int32.Max) ensures all remaining segments are included. For more information, see Server variable format. Note When using server variables like {url_path} in the Destination field, the Preserve unmatched path setting becomes less relevant because server variables give you explicit control over which parts of the URL path to include. Scenario 8: Use regex to reduce the number of rule conditions and avoid hitting limits Using regex in rule conditions can significantly reduce the number of rules required, which helps avoid rule limits that can be a blocker for customers who need conditions or actions for hundreds of clients. For example, if a customer wants to identify their clients with a specific ID pattern to allow access to a resource behind Azure Front Door, clients send a header like x-client-id: SN1234-ABCD56. This header follows a specific format: x-client-id: <SN + 4 digits + - + 4 uppercase letters + 2 digits>. Instead of creating individual rules for each possible client ID, you can use a single regex pattern ^SN[0-9]{4}-[A-Z]{4}[0-9]{2}$ to match all valid client IDs in one rule, for example, SN1234-ABCD56, SN0001-ZYXW99, SN2025-QWER12, SN9876-MNOP34, SN3141-TEST42, etc. This approach allows you to handle hundreds of different client IDs with a single rule configuration. Scenario 9: Modify origin redirects using response header captures You can make action fields dynamic by using response header values as server variables. This is useful when origin servers issue redirects that reference their own domain names. The problem: Origin servers like Azure App Service commonly issue redirect URLs that reference their own domain name (for example, contoso.azurewebsites.net). If these URLs reach the client unmodified, the next request bypasses Azure Front Door, which disrupts the user's navigation experience. The solution: Capture the origin's Location header and rewrite just the host portion so it always reflects the hostname that the client originally used. For example, if the frontend client's host header to Azure Front Door is contoso.com and the origin is contoso.azurewebsites.net, when the origin issues an absolute redirect URL like Location: https://contoso.azurewebsites.net/login/, you can modify the location header back to use the original hostname Location: https://contoso.com/login/ This is achieved using the server variable format: https://{hostname}{http_resp_header_location:33}, where: {hostname} represents the original client hostname (contoso.com) {http_resp_header_location:33} captures the Location header content starting from offset 33 (the /login/ part) For more information, see Preserve the original HTTP host name between a reverse proxy and its back-end web application. Note This rule can be used when rule condition is based on request parameters or when invoked unconditionally. For consistent offset calculation, all origin servers in the origin group should have domain names of the same length, for example, all 33 characters like https://contoso.azurewebsites.net. Ideally, there should be just one origin server, but multiple origins are acceptable if their names have identical lengths. You can apply the same server variable capture technique to extract and reuse request query string parameters in different rule actions. Scenario 10: If-elseif-else rules The Azure Front Door rules engine doesn't natively support traditional conditional logic with "if-elseif-else" structures. By default, all rules are independently evaluated as "if condition1 then action1", "if condition2 then action2", and so forth. When multiple conditions are met simultaneously, multiple corresponding actions are executed. However, you can emulate "if-elseif-else" logic by using the Stop evaluating remaining rules feature to create conditional branching that resembles: If condition1 is satisfied, execute action1 and stop Else if condition2 is satisfied (but condition1 is not), execute action2 and stop Else if condition3 is satisfied (but condition1 and condition2 are not), execute action3 and stop Else, execute a default action How it works: When multiple conditions would normally be satisfied simultaneously, only the first matching rule executes because rule evaluation stops after the first match. This effectively simulates traditional conditional branching. Configuration steps: Create a new ruleset (for example, "IfElseifElseRuleset") Create rules in priority order, with the most specific conditions first For each rule, check the Stop evaluating remaining rules option Important This if-elseif-else paradigm only works if the ruleset is attached as the final ruleset for that route. Scenario 11: Removing query strings from incoming URLs using URL redirects You can remove query strings from incoming URLs by implementing a 3xx URL redirect that guides users back to the Azure Front Door endpoint with the query strings removed. The following example demonstrates how to remove the entire query string from incoming URLs. If you need to strip part of it, you can adjust the offset/length as desired. For more information, see Server variable format. Note Users will notice the change of the request URL with this operation. Scenario 12: Append SAS token in query string to authenticate Azure Front Door to Azure Storage You can protect files in your storage account by changing the access to your storage containers from public to private and using Shared Access Signatures (SAS) to grant restricted access rights to your Azure Storage resources from Azure Front Door without exposing your account key. You can also accomplish this using Managed Identity. For more information, see Use managed identities to authenticate to origins. How SAS token injection works: Capture the incoming URL path and append the SAS token to the query string using redirect or rewrite rules. Since URL rewrite only acts on the path, use redirect rules when you need to modify query strings. For example, if you want to append a SAS token to the incoming URL: https://www.contoso.com/dccp/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399, the rewrite URL will be: https://www.contoso.com/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399&<SASTOKEN> In this example, the incoming URL already has query parameters, and you want to preserve the existing query string while appending the SAS token by configuring URL redirect using /{url_path:seg1:20}?{query_string}&<SASToken>. The rule configuration redirects all HTTPS requests that don't already contain the SAS token (identified by the absence of sp=rl in the query string). Important Update your route configuration to ensure routes for /grammars/* are properly configured after the redirect Replace the SAS token with the proper token. In the example, the SAS token starts with sp=rl, and you want to redirect all requests to apply this rule which doesn’t contain the sp=rl Scenario 13: Add security headers with rules engine You can use the Azure Front Door rules engine to add security headers that help prevent browser-based vulnerabilities, such as HTTP Strict-Transport-Security (HSTS), X-XSS-Protection, Content-Security-Policy, and X-Frame-Options. See details in Tutorial: Add security headers with Rules Engine - Azure Front Door | Microsoft Learn. Conclusion In this blog, we explored common scenarios where you can leverage the AFD rules engine to streamline and customize your workflows. We're enhancing the engine to be more flexible and scalable—supporting advanced routing, origin selection, and edge-side processing. More updates are on the way, so stay tuned. In the meantime, we’d love your input: what scenarios are you trying to unblock? Whether you're optimizing for performance, reliability, or custom workflows, drop your thoughts in the comments—we're listening and excited to see what you’ll build.
Azure WAF Integration in Security Copilot is Now Generally Available
We’re excited to announce the general availability (GA) of Azure Web Application Firewall (WAF) integration with Microsoft Security Copilot. This marks a significant advancement in web application protection, bringing together Azure WAF’s industry-leading defense with the AI-powered capabilities of Security Copilot to transform how security teams detect, investigate, and respond to threats. Why This Integration Is a Game-Changer Modern web applications face relentless threats - from SQL injections and cross-site scripting (XSS) to bot attacks and sophisticated Layer 7 DDoS attempts. Defending against these threats requires more than just reactive measures; it demands intelligent, scalable solutions. With Azure WAF now integrated into Security Copilot, security teams can gain: Proactive threat analysis: Quickly uncover attack patterns and identify emerging threats. Optimized WAF configurations: Use AI insights to fine-tune rules and policies. Accelerated investigations: Leverage Copilot’s generative AI to streamline incident triage and response. This integration enables teams to work smarter and faster - turning raw data into actionable intelligence with the help of natural language prompts and AI-guided workflows. Seamless Protection Across Azure Platforms Azure WAF protects applications behind Azure Front Door and Azure Application Gateway, offering centralized, cloud-native security at scale. Now, with Security Copilot, analyzing WAF diagnostic logs no longer requires manual parsing or deep scripting expertise. Instead, AI delivers contextual insights directly to your SOC teams, cloud admins, and DevSecOps engineers. Whether you're investigating blocked requests or tuning security policies, this integration helps reduce operational overhead while strengthening your overall security posture. What Can You Do with Azure WAF in Security Copilot Let’s explore some of the core capabilities now available: SQL Injection (SQLi) Attack Analysis Understand why Azure WAF blocked specific SQLi attempts through detailed summaries of diagnostic logs and correlation of related events over time. Cross-Site Scripting (XSS) Attack Insights Get clear explanations for WAF’s enforcement actions against XSS attacks, with trend analysis across your environment. Top Offending IPs Analysis Identify the most malicious IPs triggering WAF rules, along with insights into the behaviors and rule patterns that led to their blocking. Most Triggered Rules and Actions Gain visibility into your most active WAF rules - helping prioritize tuning efforts and enhance threat detection effectiveness. These capabilities are designed to turn WAF data into actionable knowledge - without the need for custom queries or extensive log review. Built for the Future of Intelligent Security As threats continue to evolve, so must our defenses. The Azure WAF and Security Copilot integration represents the next generation of web application protection - combining automation, AI reasoning, and expert knowledge to deliver adaptive security at cloud scale. By augmenting your team with AI, you can stay ahead of attackers, protect critical apps, and respond faster than ever before. Learn More and Get Started The GA of Azure WAF integration in Microsoft Security Copilot is more than just a feature release - it’s a new paradigm for web application security. Explore the capabilities today by visiting the Azure WAF documentation. Want to talk to us? Reach out to the Azure WAF product team to share feedback or request a demo. Let’s build a more secure web, together.Securing web applications with Azure Front Door WAF CAPTCHA (Preview)
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 LearnPublic Preview of Azure WAF CAPTCHA Challenge for Azure Front Door
Modern web applications face an ever-growing array of automated threats, including bots, web scrapers, and brute-force attacks. Many of these attacks evade traditional security measures such as IP blocking, geo-restrictions, and rate limiting, which struggle to differentiate between legitimate users and automated traffic. As cyber threats become more sophisticated, businesses require stronger, more adaptive security solutions. Azure Front Door’s Web Application Firewall (WAF) now introduces CAPTCHA in public preview—an interactive mechanism designed to verify human users and block malicious automated traffic in real time. By requiring suspicious traffic to successfully complete a CAPTCHA challenge, WAF ensures that only legitimate users can access applications while keeping bots at bay. This capability is particularly valuable for common login and sign-up workflows, mitigating the risk of account takeovers, credential stuffing attacks, and brute-force intrusions that threaten sensitive user data. Key Benefits of CAPTCHA on Azure Front Door WAF Prevent Automated Attacks – Blocks bots from accessing login pages, forms, and other critical website elements. Secure User Accounts – Mitigates credential stuffing and brute-force attempts to protect sensitive user information. Reduce Spam & Fraud – Ensures only real users can submit comments, register accounts, or complete transactions. Easy Deployment & Management – Requires minimal configuration, reducing operational overhead while maintaining a robust security posture. How CAPTCHA Works When a client request matches a WAF rule configured for CAPTCHA enforcement, the user is presented with an interactive CAPTCHA challenge to confirm they are human. Upon successful completion, Azure WAF validates the request and allows access to the application. Requests that fail the challenge are blocked, preventing bots from proceeding further. Getting Started CAPTCHA is now available in public preview for Azure WAF. Administrators can configure this feature within their WAF policy settings to strengthen bot mitigation strategies and improve security posture effortlessly. To learn more and start protecting your applications today, visit our Azure WAF documentation.
