Azure WAF: when to use custom rules before managed OWASP rules

Managed OWASP/CRS or DRS rules protect against many classes of application attacks, but they do not carry all the business logic of a web exposure. Sometimes the right control is not an exclusion. It is a custom rule that blocks or allows very specific traffic before the request reaches the rest of WAF analysis.

The scenario here is an application published behind Azure Application Gateway WAF. The team sees blocks, false positives and noise. It must decide when to adjust a managed rule, when to create an exclusion, and when to use a custom rule to express a simpler access policy: country, IP, header, method, path or specific condition.

Running use case: /admin should not be public

The same partner portal exposes an /admin area used by the support team. Application authentication remains mandatory, but the organization wants to reduce exposure: only support workstations leaving through 198.51.100.0/24 should reach that route. Partners and the Internet should never see the endpoint, even if their requests do not trigger any OWASP rule.

This is not a WAF false positive. There is no reason to create an exclusion. The need is an HTTP access policy: block /admin for any source outside the expected network. That is a typical custom rule use case.

Do not use an exclusion for access control

An exclusion removes part of the request from inspection by a rule or rule group. It is not an access-control mechanism. If the need is to block an IP, limit an HTTP method or protect an administration path, a custom rule is often more readable.

Need: the comment parameter incorrectly triggers a SQLi rule
Likely option: targeted per-rule exclusion

Need: /admin must be reachable only from internal IPs
Likely option: custom block or allow rule based on IP and path

Need: block TRACE and OPTIONS methods on the Internet
Likely option: custom rule on RequestMethod

Need: disable an entire OWASP rule for the whole site
Option to avoid unless strongly justified and temporary

This separation clarifies governance. Managed rules handle attack signatures. Custom rules express application-specific publication constraints.

Understand processing order

In Azure WAF, custom rules have a priority and are evaluated before managed rules. That means a block rule can stop a request before OWASP rules see it. This is powerful, but it can also hide signals if the rule is too broad.

Logical order
1. Custom rules by priority
2. Managed OWASP/CRS or DRS rules
3. Final decision according to policy and mode

Consequence
An overly broad custom rule can reduce visibility into managed rules
A precise custom rule can reduce noise and block unwanted traffic early

Priority must be documented. A global IP block does not have the same impact as a rule targeted at /admin.

Example custom rule by path and IP

A classic case is limiting an administration path to a few sources. The WAF does not replace application authentication, but it can reduce HTTP exposure.

RG=rg-network-prod
POLICY=wafpol-app-prod

az network application-gateway waf-policy custom-rule create --resource-group $RG --policy-name $POLICY --name block-admin-outside-trusted --priority 100 --rule-type MatchRule --action Block --match-conditions '[
  {
    "matchVariables": [{"variableName": "RequestUri"}],
    "operator": "Contains",
    "matchValues": ["/admin"]
  },
  {
    "matchVariables": [{"variableName": "RemoteAddr"}],
    "operator": "IPMatch",
    "negationConditon": true,
    "matchValues": ["198.51.100.0/24"]
  }
]'

The negationConditon field is intentionally written as it appears in the Azure Application Gateway WAF model. That historical API typo often looks wrong during review; changing it to negationCondition can break the example depending on the tool. In infrastructure as code, follow the schema of the provider actually used and avoid automatically correcting that property name.

This example illustrates the intent, not a universal copy-paste. In production, verify the exact CLI syntax used by the team, prefer infrastructure as code when it is the standard, and test the rule in a non-critical environment.

Monitor the effect in logs

A custom rule must be observable. After creation, check block volume, affected paths and sources. If the rule blocks much more than expected, it is too broad or poorly ordered.

AzureDiagnostics
| where TimeGenerated > ago(24h)
| where Category == "ApplicationGatewayFirewallLog"
| where ruleId_s has "block-admin-outside-trusted" or message_s has "block-admin-outside-trusted"
| summarize blocks=count(),
          clients=dcount(clientIp_s),
          sampleUri=any(requestUri_s)
by hostname_s, action_s
| order by blocks desc

Depending on the log format, the custom rule name can appear in different fields. The important part is having a follow-up query before considering the change complete. On a critical policy, prepare that query before the change, with a monitoring window and rollback threshold.

For /admin, the useful test has two sides: a request from 198.51.100.0/24 should continue to application authentication, while a request from an external IP should be blocked by the custom rule. If both cases are not tested, the rule may be either ineffective or too restrictive.

Keep managed rules as the baseline

Custom rules should not become a handmade replacement for OWASP. They are useful to express a clear local policy. Managed rules remain the baseline protection against general attack classes. When a custom rule blocks suspicious traffic early, it can also prevent seeing which OWASP rules would have reacted. That is not always a problem, but it must be understood.

Review questions
Does the custom rule express an access or publication requirement?
Is the priority justified?
Does the rule hide useful OWASP signals?
Is there a KQL monitoring query?
Is rollback documented?

Conclusion

An Azure WAF custom rule is relevant when the need is to express a precise access policy: block a path, method, source or simple combination of conditions. An exclusion is relevant when a managed rule inspects a legitimate part of the request too aggressively.

A good design keeps responsibilities separate. Custom rules carry exposure-specific constraints. OWASP/CRS or DRS rules remain the detection baseline. Exclusions stay targeted and justified. That separation improves the WAF without making it unreadable.