Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
If a request matches more than one page type, how are the rules applied (exact path priority, glob rules merged with Any Paths)?
Short answer
The order is fixed and independent of the position in the list: if there is an exact rule identical to the path of the request, that rule is taken as the basis; if there is no exact rule, all the glob rules that match the path are taken together; if none of them matches, Any Paths is applied on its own (runtime rule matching). The path settings (Allowed Methods, Path Length, Path Depth, path OWASP) are not inherited: if an exact rule has matched, its settings are applied, and if glob rules have matched, those of the matching glob rule defined first are applied. The Check Fields sections and argument rules that the exact rule does not define are completed from the matching glob rules first and, if they are not there either, from Any paths. When the glob rules and Any paths are combined, the setting of every section and argument comes from the rule that defines it first; if several globs define the same section or argument, the glob defined first (added first) wins.
How Does It Work?
| Step | Condition | Applied |
|---|---|---|
| 1 | There is an exact rule identical to the path | The path settings from the exact rule; the sections and arguments it does not define from the matching glob rules (in the order of definition), then from Any paths |
| 2 | There is no exact rule, there are matching glob rule(s) | The matching glob rules are combined in the order of definition, with Any paths added at the end; the path settings from the first glob rule |
| 3 | No rule matches | Only Any paths (How is a request that matches no page type inspected?) |
In the matching, the path of the request is used: the query string is not included, the trailing / is removed, and the matching is case-sensitive.
Where Does What Come From?
| Setting | Its source |
|---|---|
| Allowed methods, Path length, Path depth, path OWASP | The exact rule or the matching glob rule defined first; not inherited from Any paths |
| Check fields section (Query, Header, JSON, Xml, Form, Raw) | The rule that defines the section first |
| A single argument rule within a section | The rule that defines the argument first |
- Glob rules stand in the list below the exact rules, in the order they were added; a glob rule produced with Merge or a glob rule added later is added to the end of the glob part of the list.
- In the detail panel of an exact rule, the inherited sections and arguments appear in italics and the Rule Source row shows which rule the field comes from; in the panel of a glob rule, the inherited settings are not listed (How do inheritance and "Rule Source" work in rules?).
- In the Event Logs record, the Matching Path Rules row on the Request & Location tab shows the rules the request matched, and the Corresponding Rule row on the Attacks tab shows the rule the attack matched (preview of the selected log).
Defining the critical sections in the glob rule itself
If the common rule of a certain section (e.g. Query or Header) and the OWASP Check setting on the paths a glob rule covers are to be known for certain, that section is defined in the glob rule itself (in the detail panel, the relevant tab → Add Common Rule for …). In this way, the check is done with the rule's own setting, independent of the order in the combination.
Common Misconceptions
- "The most specific glob wins." It is not the specificity but the order of definition that determines it; among the globs that define the same section, the one defined first wins.
- "The exact rule inherits the method list of Any paths." The path settings are not inherited; if the exact rule was left with Any Methods, there is no method restriction on that path.
- "The rule at the top of the list is always applied first." The priority among exact, glob and Any paths is independent of the list; the order of definition matters only among glob rules.
How it is done in the documentation
