Build WAF policy configs with custom rules for IP blocking, rate limiting, geo-filtering, and OWASP managed rule set overrides.
Output will appear here...Build an Azure WAF custom rule policy combining match conditions (IP, geo, header, body, query string matching) with either a MatchRule (simple condition-based block/allow/log) or RateLimitRule type, evaluated in Priority order (lower numbers evaluated first) alongside whatever managed rule set (OWASP Core Rule Set) is separately configured on the policy. mode set to Detection (versus Prevention) means matched requests are logged but not actually blocked, a genuinely different operational state from Prevention that's easy to leave on longer than intended during a 'let's validate the rules first' rollout, silently providing zero actual protection while looking fully configured.
No, Detection mode logs what would have matched and, for a Block-actioned rule, what would have been blocked, but doesn't actually block or otherwise act on the traffic. It's meant as a validation stage before switching to Prevention, if a policy is left in Detection mode indefinitely (a common oversight after an initial rollout), it provides visibility into traffic patterns but zero actual request blocking.
A MatchRule fires on every request matching its conditions, immediately. A RateLimitRule only fires once a source (typically identified by IP, depending on configuration) exceeds rateLimitThreshold requests within rateLimitDuration, it's specifically for throttling abusive volume rather than blocking every single matching request outright, appropriate for credential-stuffing or scraping patterns where the individual requests might look legitimate but the aggregate rate doesn't.
They're evaluated as separate rule sets within the same policy, custom rules (with their own Priority ordering) generally get evaluated, and the managed rule set (OWASP CRS) is evaluated separately with its own rule matching, both contributing to the policy's overall decision for a given request. A custom rule can be used specifically to override or exempt traffic from a managed rule's default behavior (an exclusion), but they're not simply merged into one single priority-ordered list.
The tool validates policyName is present and each rule has a name, at least one match condition with a non-empty matchValues, and (for RateLimitRule types) a defined threshold and duration, then constructs the WAF policy JSON matching Azure's expected custom rule schema; it can't verify the configured match conditions and rate limit thresholds are appropriately tuned for your actual traffic patterns, that's a judgment call requiring observation of real traffic, not something schema validation can determine.
Never leave a policy in Detection mode indefinitely after the initial validation period, it's a common and easy-to-overlook state that provides the appearance of WAF protection (a policy exists, rules are configured) with none of the actual blocking benefit.
Rate limit rules are the right tool for abusive-volume patterns where individual requests look legitimate, don't reach for a hard IP block as the default response to suspected credential stuffing or scraping when a rate limit achieves the goal with less collateral risk of blocking legitimate shared-IP traffic.
Priority ordering across custom rules needs the same deliberate design as any other priority-evaluated rule system, a broad rule with a lower priority number than a more specific one can shadow it entirely, verify actual evaluation order matches intent, don't assume rule order in the configuration file reflects evaluation order.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.