Ruleset Engine architecture
Rules execute in product phases. The ruleset scope, phase and order determine which request fields and actions apply.
Rules, rulesets and phases
A rule combines a boolean filter expression with an action. Rules are ordered inside a ruleset, and each ruleset executes in a defined request or response phase. Products such as redirects, URL rewrites, origin rules, WAF, rate limiting, header transforms and cache rules occupy different phases.
Choose the correct rule family
Use a WAF Custom Rule to allow, block, challenge, skip or log matching requests. Use Rate Limiting Rules for request-rate thresholds. Use Redirect Rules to change the visitor URL, Transform Rules to rewrite request or response properties, Origin Rules to change upstream routing, and Cache Rules to control cache eligibility and settings.
Expressions and fields
Expressions compare request or response fields with values and combine conditions using not, and, xor and or. String comparisons are case-sensitive unless a function or operator explicitly changes that. Parenthesize mixed logical expressions so precedence is obvious.
- Start with hostname, path, method and a stable authentication or network property.
- Use true only when the action must apply to every request in that phase.
- Avoid depending on a header that an untrusted client can freely forge.
Expressions, order and actions
Expressions select traffic; action semantics and termination decide whether later rules in the phase can still affect it.
Order and terminating actions
Non-terminating changes in the same phase can be overwritten by later matching rules. Block, redirect and challenge actions terminate evaluation for that request in the relevant phase. If several redirects could match, the first applicable terminating redirect wins. Product phase order can also mean one rule family changes fields later rules see.
WAF Custom Rules and exceptions
Match the smallest stable scope that expresses the application policy. Use Managed Challenge where legitimate humans may share a suspicious characteristic, Block where traffic must never reach the application, and Skip only for the specific products and paths that genuinely require an exception. A false positive should not lead to disabling the complete WAF.
Rule families
WAF, rate limiting, redirects, transforms, origin and cache rules each own a distinct part of request processing.
Rate limiting design
Choose a match expression, counting characteristic, requests per period, mitigation action and mitigation duration from measured legitimate behaviour. Separate login, API and expensive application endpoints from static assets. Distributed edge enforcement is a protection control, not an exact origin request counter.
Redirects and URL rewrites
Use a permanent 301 only when the move is intended to remain stable; use a temporary redirect while the destination may change. Confirm path substitution, query-string handling, percent encoding and loop prevention. A rewrite changes the internal request URI while a redirect instructs the client to make another request.
Testing and recovery
Every rule needs a matching request, a non-matching request and a narrow rollback that preserves the rest of the policy.
Cache and origin rules
Cache only responses safe to share between matching visitors, and define a cache key that contains every dimension that changes content. Origin Rules can change upstream hostname, port or DNS destination; verify TLS SNI and Host-header expectations. A custom cache key can change which purge operation reaches an object.
Test and recover a rule
Use one request that must match and one that must not. Inspect the resulting status, redirect location, response headers, cache status and Security Event. If legitimate traffic is affected, disable the specific rule or restore its previous order first; remove emergency bypasses after replacing them with a narrow proven condition.
