Troubleshooting Lab: Map requirements to features and capabilities of WAF
Diagnostic Scenarios
Scenario 1 — Root Cause
A security team configured an Azure Web Application Firewall (WAF) in Prevention mode associated with an Azure Application Gateway v2. The protected application is a corporate web portal accessible from the internet.
After activation, legitimate users began reporting that certain requests are blocked with HTTP 403 responses. The team reviewed the logs and found the following:
{
"timeStamp": "2025-03-10T14:22:31Z",
"resourceId": "/subscriptions/.../applicationGateways/agw-prod",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_0",
"clientIp": "203.0.113.45",
"requestUri": "/api/search?q=1+1%3D1",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.2",
"ruleId": "942100",
"message": "SQL Injection Attack Detected via libinjection",
"action": "Blocked",
"hostname": "portal.contoso.com",
"transactionId": "abc123"
}
}
Additional details provided by the team:
- The WAF uses CRS 3.2 without customizations
- The application uses authentication via Microsoft Entra ID with JWT tokens
- The
qfield in the URL is a free search field that accepts mathematical expressions as valid user input - The Application Gateway TLS certificate was renewed the previous week
- No rule exclusions are configured in the WAF Policy
What is the root cause of the problem?
A) The renewed TLS certificate changed the behavior of payload inspection by the WAF for encrypted traffic.
B) Authentication via Microsoft Entra ID with JWT tokens generates headers that conflict with CRS rule 942100.
C) The WAF in Prevention mode is blocking valid user input that matches a SQL injection pattern in CRS rule 942100, without exclusion configured for this field.
D) CRS 3.2 has a known bug that blocks mathematical expressions in URL parameters regardless of context.
Scenario 2 — Side Impact
The security team of a company identified that the WAF associated with an Azure Front Door Premium was operating in Detection mode since deployment, never having been promoted to Prevention mode. The decision was made to promote the mode immediately to Prevention in production, without an additional period of log analysis.
The promotion was performed successfully. The next day, the operations team confirmed that no attacks were recorded in the blocking logs.
What side consequence can this action cause?
A) Azure Front Door Premium automatically enters maintenance mode when detecting a WAF policy change, generating temporary unavailability.
B) Legitimate requests that historically matched CRS rules and were not investigated during the Detection period may start being blocked, causing false positives in production.
C) WAF in Prevention mode automatically disables Detection logs, preventing the team from continuing to monitor unblocked attack attempts.
D) Changing to Prevention invalidates all previously configured rule exclusions, requiring them to be recreated manually.
Scenario 3 — Root Cause
A company deployed a WAF Policy associated with an Azure Front Door Premium to protect a REST API. The security requirement mandates that requests originating from a specific set of business partner IP addresses should be always allowed, regardless of CRS rules.
The team configured the following custom rule set in the WAF Policy:
| Priority | Name | Type | Condition | Action |
|---|---|---|---|---|
| 10 | BlockHighRisk | MatchRule | GeoMatch: CN, RU, KP | Block |
| 50 | AllowPartners | MatchRule | IPMatch: 198.51.100.0/24 | Allow |
| 100 | DefaultDeny | MatchRule | RequestUri: / | Block |
After deployment, a partner reports that their requests originating from 198.51.100.15 are being blocked with 403 response before reaching the API. The logs show that the BlockHighRisk rule is being triggered for these requests.
Additional information:
- Front Door Premium is configured with WAF Policy in Prevention mode
- The partner confirmed that the IP address
198.51.100.15is a fixed corporate IP - The network team verified that there is no NAT or proxy between the partner and Front Door
- The partner's domain was recently registered in a different TLD than usual
What is the root cause of the problem?
A) The partner's domain registered in a different TLD is being interpreted by the WAF as a suspicious origin, triggering the BlockHighRisk rule.
B) The GeoMatch condition of the BlockHighRisk rule is classifying IP 198.51.100.15 as belonging to one of the blocked countries, and since this rule has lower priority than AllowPartners, it is evaluated first and blocks the request.
C) Prevention mode in WAF on Front Door Premium evaluates all custom rules before applying any Allow action, which causes the Block from the lower priority number rule to prevail.
D) The AllowPartners rule with priority 50 is evaluated after the BlockHighRisk rule with priority 10, therefore the partner's request is blocked before the allow rule is evaluated.
Scenario 4 — Action Decision
The security team identified that the WAF Policy associated with an Application Gateway v2 is blocking legitimate requests from an internal integration system. Investigation confirmed that CRS rule 942450 is interpreting a custom header field from the system as a SQL encoding pattern.
Context and constraints:
- The environment is production with 99.9% SLA
- The integration system processes critical financial orders and cannot be modified to change the header format
- The maintenance window is Friday night, but the impact has been occurring since Monday
- The team has write permission on the WAF Policy
- No other WAF Policy is applied to the Application Gateway
- Changing mode to Detection would resolve the blocking but remove protection from all other rules
What is the correct action to take at this moment?
A) Change the WAF Policy to Detection mode immediately to restore integration system functionality while a definitive solution is prepared.
B) Wait for Friday's maintenance window to configure a specific rule exclusion for rule 942450 on the affected header.
C) Immediately configure a rule exclusion in the WAF Policy for rule 942450 applied to the specific custom header, without changing the WAF mode or disabling other rules.
D) Completely disable the SQL Injection rule group in CRS to eliminate false positives related to SQL encoding throughout the entire application.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
WAF in Prevention mode blocks requests that match CRS rules before any application logic is executed. Rule 942100 detects SQL Injection patterns via libinjection, and the expression 1+1%3D1 (which decodes to 1+1=1) matches this pattern. Since no rule exclusions are configured, the match results in immediate blocking.
The central clue is in the combination of three elements from the scenario: WAF is in Prevention mode, no exclusions are configured, and the search field accepts mathematical expressions as valid input. This is a classic WAF false positive with CRS without fine-tuning.
The information about TLS certificate renewal is irrelevant. WAF in Application Gateway inspects traffic after TLS termination, so certificate changes don't affect payload inspection rules.
The most dangerous distractor is B, as it directs investigation to Microsoft Entra ID JWT tokens, a component present in the environment but without causal relation to the blocking. Acting based on this would lead to authentication layer investigation that wouldn't solve the problem.
Answer Key — Scenario 2
Answer: B
The Detection mode period serves exactly to identify which legitimate requests match CRS rules before activating blocking. When this analysis isn't performed and the mode is promoted directly to Prevention, all matches that existed silently start generating actual blocks.
The clue is in the scenario: WAF operated in Detection since deployment without log analysis, and the promotion was done without additional review period. The absence of blocking records the next day doesn't confirm everything is working correctly: it may indicate that legitimate traffic is being blocked and users haven't reported yet.
Distractor C is technically false: Prevention mode doesn't disable Detection logs; both log types remain available.
Answer Key — Scenario 3
Answer: D
In Azure WAF Policies, custom rules are evaluated in ascending numerical priority order. The rule with the lower number is evaluated first. The BlockHighRisk rule has priority 10 and the AllowPartners rule has priority 50. When IP 198.51.100.15 matches the GeoMatch condition of the priority 10 rule, the Block action is applied immediately and evaluation stops. The priority 50 rule is never reached.
The correct solution would be to assign the AllowPartners rule a numerically lower priority than BlockHighRisk, for example priority 5, so it's evaluated first.
The information about the partner's domain TLD being different is irrelevant. WAF evaluates GeoMatch based on source IP address, not the request's domain or TLD.
Distractor B contains a subtle but critical inversion: it states that the BlockHighRisk rule has lower priority than AllowPartners, which is the opposite of what's in the table. Readers who don't pay attention to the priority field meaning mark this distractor as correct.
Answer Key — Scenario 4
Answer: C
Rule exclusion in WAF Policy allows suppressing a specific CRS rule for a specific request attribute, such as a header, parameter, or cookie, without affecting any other rule or changing the WAF's operation mode. This is the correct surgical action for a confirmed false positive with identified cause.
The constraint context eliminates other alternatives: alternative A removes protection from all rules by changing to Detection, which is disproportionate to the problem. Alternative B ignores the production impact that has lasted for days and the 99.9% SLA, making waiting for the maintenance window unacceptable. Alternative D disables the entire SQL Injection rule group, exposing the application to real SQL injection attacks to solve a problem restricted to a single rule and single header.
The most dangerous distractor is A, as it resolves the symptom immediately but at the cost of complete application protection in production, which may be more damaging than the original impact.
Troubleshooting Tree: WAF on Azure
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
When facing a real WAF problem, start at the root node describing the observed behavior and answer each question based on what is directly verifiable: WAF operation mode, presence of logs, type of rule that generated the blocking, and configuration of exclusions or custom rules. Each branch narrows the diagnosis to a red cause identification node, followed by the corresponding green action. If the action doesn't completely resolve, return to the last orange validation node and explore the alternative path.