?x=.js to its address. The researcher subsequently said other query values containing .js, including .jsp and .jsanything, produced the same result. The cause remained under investigation.The important question is not simply whether the response changed. It is which component denied the original request, and why the modified request was treated differently.
What the report establishes—and what it does not
Pillitteri describes a screenshot and video involving an error page bearing Microsoft-Azure-Application-Gateway/v2. However, the account does not disclose the gateway configuration, protected resource, backend application, or policy responsible for the denial. His October 24 report identifies no linked CVE, Microsoft advisory, vendor response, or independent reproduction. Those are the limits of that reporting, not proof that no subsequent determination exists.
Consequently, this is a reported response bypass in an unspecified deployment—not evidence that adding a query parameter opens arbitrary Azure-hosted applications.
“Application Gateway v2” does not automatically mean WAF
Microsoft describes Application Gateway as an application-layer load balancer that routes web requests using attributes such as URL paths and host headers. Its v2 family includes Standard_v2 and WAF_v2. The product family therefore matters: seeing “v2” does not, by itself, establish that a web application firewall was involved.
Microsoft’s HTTP 403 troubleshooting guidance makes another essential distinction:
- Prevention mode: WAF can block requests.
- Detection mode: WAF logs matches rather than blocking traffic.
- Standard_v2: The SKU does not support Application Gateway WAF.
A branded error page is a starting point for investigation, not a diagnosis.
A useful configuration check: custom allow rules
Microsoft documents that custom WAF rules are evaluated before managed rules, and a matching custom Allow action prevents managed rules from blocking the request. That gives administrators a concrete reason to inspect their own allow rules alongside managed-rule exclusions and overrides.
This is not an explanation of Gospel’s observation. It is a documented configuration mechanism that investigators should rule out before concluding that the managed inspection engine has a defect. A product flaw and an overly broad policy can produce similar-looking symptoms while requiring very different remedies.
How administrators can investigate safely
The sensible response is a controlled diagnostic comparison, not a production-wide policy rewrite.
1. Establish the deployed configuration
Record the SKU, applicable WAF policy, operating mode, managed ruleset, and relevant custom rules. Microsoft’s troubleshooting process begins with these checks because they determine whether WAF could have generated the denial.
2. Confirm that logs are actually being collected
Microsoft says Application Gateway resource-log collection must be enabled through Azure Monitor diagnostic settings. Collect access logs and, where applicable, firewall logs. Log Analytics is Microsoft’s recommended destination for querying and alerting.
Check the collection schema before copying a query:
- Legacy collection uses
AzureDiagnostics. - Resource-specific collection uses tables including
AGWAccessLogsandAGWFirewallLogs.
An empty query against the wrong table—or a gateway without collection enabled—cannot establish that no security rule fired.
3. Compare requests only within an authorized environment
On a gateway you own or are explicitly authorized to assess, preserve the baseline request and query-string variant, including timestamps, headers, authentication state, responses, and corresponding backend records.
The diagnostic goal should be clear: determine whether the original request was blocked by WAF, whether the variant reached the backend, and whether it returned the same protected content. Do not treat a changed status code alone as a complete security finding.
Avoid a speculative “fix”
Do not assume that blocking every query containing .js resolves an unidentified cause. Such a rule would be a hypothesis-driven workaround, not a verified mitigation.
Nor should administrators disable protection merely to investigate this report. Microsoft’s WAF best practices recommend tuning policies for the workload and using Prevention mode afterward; Detection mode logs traffic but provides no blocking protection.
As a general defense-in-depth principle, sensitive application resources should enforce their intended authorization independently of attack filtering. That recommendation is not evidence that the unnamed application lacked authorization.
The practical takeaway is measured: identify the source of the 403, inspect policy decisions, and preserve reproducible evidence. Investigate the behavior without promoting an unexplained response change into a platform-wide vulnerability claim.