Best Practices for Configuring Azure Application Gateway WAF for a Legacy Oracle Agile PLM Java/WebLogic Application

Continue using managed rules as the security baseline, but refine the design by moving recurring endpoint-specific false positives into narrowly scoped per-URI policies or rule-scoped exceptions rather than accumulating global exclusions.

Recommended architecture and tuning model

Your Detection → log analysis → targeted exclusion → retest → Prevention process is Microsoft’s recommended methodology. False positives and application-specific tuning are expected, particularly with older applications. Detection mode should remain temporary because it records attacks but does not block them.^1^

Use this order of preference:

1. Managed DRS as the baseline. Do not replace SQLi, XSS, Java, and protocol protections with application-specific custom rules.
2. Per-rule exclusion when one named argument, cookie, or header causes a confirmed false positive for one or a few rules.
3. Per-URI policy or exception when the behavior belongs to a specific endpoint, such as file upload, XML integration, search, or workflow APIs.
4. Rule action override/disablement only when the rule produces false positives across many inputs and its loss is understood.
5. Custom Block or Log rules for application-specific restrictions such as trusted networks, methods, headers, geo-filtering, or known hostile patterns.
6. Custom Allow rules only as a last resort, because a matching Allow rule stops subsequent managed-rule inspection.^2^

Microsoft does not publish an Oracle Agile PLM-specific policy, so the appropriate configuration must be derived from observed Agile/WebLogic traffic.

Tighten the existing exclusions

For each current exclusion, record:

• Listener, path, and operation that require it.
• Ruleset version, rule group, and contributing rule ID.
• Exact match variable and selector.
• Sample transaction ID demonstrating the false positive.
• Compensating application control and review owner.

Prefer Equals over Contains, StartsWith, or EqualsAny, and scope the exclusion to the contributing rule—not the anomaly-score rules such as 949110 or 980130. An exclusion omits only the selected attribute while the rest of the request remains inspected.^3^

Yes, an exclusion creates risk: an attacker can place a payload in the excluded field, and the affected rules will not inspect that field. Reduce that exposure by combining all applicable dimensions:

• Exact parameter or cookie name.
• Individual SQLi/XSS rule IDs.
• A dedicated listener or URI policy.
• Server-side validation, authorization, safe query parameterization, and output encoding.

Review global exclusions first. A global field exclusion affects every managed rule and every location where that policy is associated.^4^

A relevant limitation for Agile’s XML traffic is that XML request bodies are not supported by WAF exclusion selectors. If the false positive is inside raw XML, use endpoint scoping and a rule-scoped URI exception rather than assuming an argument-name exclusion can isolate the XML element.^3^

Use endpoint-aware policies

Application Gateway WAF v2 policies can be associated globally, per listener, or with a path-based rule. A per-URI policy overrides the broader listener or global policy.^5^

A practical Agile split might be:

• General UI and authentication: full managed rules with only exact, rule-scoped field exclusions.
• Upload/download paths: separate policy for upload-specific limits and false positives.
• XML/integration endpoints: separate path policy, with exceptions limited to particular rules.
• Administrative/user-management paths: strict policy with minimal or no exclusions.

WAF exceptions can match URI, remote IP, or request header and bypass only selected rules, rule groups, or rulesets. They require CRS 3.2, DRS 2.1, or later; keep them per-rule wherever possible.^6^

Avoid a custom Allow rule for a normal public Agile endpoint: it bypasses DRS/CRS and Bot Protection completely for matching requests.^6^

Ruleset strategy

Check the active ruleset before further tuning. If it is CRS 3.x or DRS 2.1, plan a controlled move to DRS 2.2, which is the current recommended version and provides Java protections and fewer false positives. DRS 2.2 defaults to Paranoia Level 1; its PL2 rules are disabled unless explicitly enabled.^7^

Treat the upgrade as a separate tuning cycle:

1. Export the policy and exclusions as code.
2. Reconcile removed or renamed rules.
3. Validate newly introduced rules in Log mode.
4. Test in nonproduction.
5. Deploy and monitor before changing enforcement.

Do not switch versions casually in the portal: assigning a new ruleset there resets rule-state, action, and rule-level exclusion customizations for the managed ruleset.^7^

Prevention-mode readiness

There is no fixed “zero matches” criterion. Enable Prevention when:

• Every high-volume legitimate workflow has been exercised.
• Each remaining match is classified as malicious, expected-to-block, or accepted residual risk.
• Authentication, uploads, XML APIs, search, workflows, and administration have regression tests.
• Exclusions are rule-scoped and documented.
• Application owners can correlate WAF transaction IDs with WebLogic logs.
• Alerts exist for blocked requests, managed-rule spikes, failed requests, and backend health.

Roll out by the narrowest available scope: enable Prevention on lower-risk listeners or URI paths first, observe a complete business cycle, and then expand. Microsoft describes a typical initial tuning interval as approximately one to two weeks, but production seasonality and infrequent Agile workflows may require longer coverage.^8^

Store the entire policy—including exclusions and overrides—in Bicep, Terraform, PowerShell, or CLI so changes are reviewable, repeatable, and preserved across ruleset upgrades.^1^

References

1. Best practices for Azure Web Application Firewall (WAF) on Azure Application Gateway
2. Custom rules for Web Application Firewall v2 on Azure Application Gateway
3. Web Application Firewall exclusion lists
4. Troubleshoot Web Application Firewall (WAF) for Azure Application Gateway
5. Azure Web Application Firewall (WAF) policy overview
6. Azure Application Gateway WAF exceptions list
7. Application Gateway WAF CRS and DRS rule groups and rules
8. Troubleshoot WAF blocking legitimate requests (HTTP 403 Forbidden errors) in Azure Application Gateway