AzureFeeds

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:

1. Microsoft Entra External ID Tenant – configured for external-facing authentication.


2. Static Web App (SWA) – front-end code with ‘.auth login’ using Microsoft Entra ID, allowing flexibility to create a custom application.


3. Azure Front Door Premium with a WAF Policy – running DRS 2.1 managed rules.


4. 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