How do I add a new page type manually?
Short answer
On the WAF Management tab, the N page types row below the mode card of the host group is clicked; on the Page Types tab that opens, the form is opened with Add. In the form, Path is entered (it starts with /; a value that contains a wildcard such as *, ?, [ ], { } becomes a glob rule on its own, and a test table appears below it), Allowed Methods is selected (default Any Methods; Multiple Methods or None), Path Length and Path Depth are defined only in a glob rule (default No Restriction), and if the signature scanning of the path is wanted, OWASP is checked (default unchecked). With the Add button of the form, the rule is applied without a separate confirmation or deployment step; if the same path exists in the same group, a Rule collision error is given. The Check Fields inspections are defined from the tabs of the detail panel after the rule is added. The same rule is also written with waf fw-rules add in WEB-CLI.
Problem: There Is No Rule for a Path
For an endpoint that will be newly put into service or for a page that has not received traffic yet, positive inspection (allowed method, path limit, path signature scanning, field restrictions) is to be defined without waiting for learning. Until a rule is defined, the requests that come to this path are inspected with the Any Paths rule of the host group.
Solution: Two Methods
| Your situation | Suitable method |
|---|---|
| One rule at a time, from the interface | Method 1: Add form |
| Script or command line | Method 2: WEB-CLI |
| The application has an OpenAPI / Swagger definition | Bulk generation from the document → Can I generate rules automatically from my OpenAPI / Swagger file? |
| A ready-made rule set exists in another host group | Moving with a file → Can I export a host group's rule set as JSON and move it to another environment; which settings are not included in the file? |
Method 1: Add Form Recommended
- How it works The path and the path settings of the rule are written to the form; the Check fields inspections are added from the detail panel after the rule is added.
- Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → the mode card of the host group → N page types → Add
- Requirement WAF protection enabled on the vService (How do I enable WAF protection on a vService?); the host group that the rule will go to is defined
- vService type HTTP vService with WAF protection enabled
Step-by-Step Configuration
In the Left Monitor Panel, the vService is clicked on the WAF-Protected vServices tab; on the screen that opens, the WAF Management tab is selected (accessing the screen).
If the rule will be written for a specific host pattern and that group does not exist yet, it is first added from the Virtual Host Groups band (How is a Host Group added; what goes into the Virtual Host Patterns field?). The default host group is ready on every vService.
The N page types row (the pencil icon at its start or the text) below the mode card of the relevant host group is clicked; the tab with the Page types - group name title opens (Default host group for the default group).
Add on the toolbar is clicked; the form with the Add title opens. The Virtual Host Group row shows the group that the rule will be added to as read-only (Virtual Host Group).
The request path is written in the Path field (the form opens with /). The value must start with / (glob patterns that contain **, e.g. **/login, are accepted without / as well); it is case-sensitive, and the query string is not written. No / is put at the end: since the trailing / character of the request path is dropped before the matching, an exact rule in the /api/login/ form does not match the /api/login/ request; the request is compared as /api/login. If the value contains a wildcard such as *, ?, [ ], { }, the rule becomes glob; the globe icon on the right of the field becomes active, and the Input / Result test table appears below it (How are glob patterns (*, **) written; how is the path test tool used?).
From the Allowed Methods list, Any Methods (default; no method inspection), Multiple Methods (at least one method is checked from the list that opens) or None (every method counts as a violation) is selected (Can I allow only certain HTTP methods on a page (Allowed Methods)?).
The fields appear only in a glob path and while Structure Checks is on. As the operator, No Restriction (default), Less Than or Equal To, Equals To, Greater Than or Equal To or Range is selected, and the value is entered (What are the Path Length and Path Depth constraints for?).
If the signature scanning of the Path section is wanted, OWASP is checked (unchecked by default in a new rule); when it is checked, the OWASP Exclusions field appears, and the signatures to be excluded from the scanning can be selected (What does turning OWASP scanning on or off at the Page Type level mean?).
Add at the bottom of the form is clicked; the button is enabled when no error remains in the form. The rule is applied without a separate confirmation or deployment step, and the N page types number on the mode card increases. If there is a rule with the same path in the same host group, the save is rejected with the Rule collision error. In a cluster setup, with the default auto-sync, the change is also sent to the peer device automatically; if Manual Sync Mode is on, it is sent manually with Synchronize.
Check fields are added separately
The Check Fields column of the new rule starts empty. An exact rule completes the Check fields sections that it does not define from the glob rules that match the path and from Any paths; in a glob rule, the common rule of the sections that must be protected is defined in the rule itself. For a field inspection specific to the rule, the new row in the list is clicked, and in the detail panel on the right, the relevant tab (Query, Header, JSON, Xml, Form, Raw) is selected and Add Common Rule for … or Add Argument Rule for … is used (How do I make sure only the query parameters I allow reach a page (Allowed Query Parameters)?).
Verification
The new row is clicked in the Page types list; the Path tab of the detail panel on the right is examined.
Allowed methods and OWASP check with the entered valuesA request that violates the rule is sent to the path of the rule (e.g. with a method that is not allowed), and in the preview of the Event Logs record, the Matching Path Rules row on the Request & Location tab is examined.
The path of the new ruleMethod 2: WEB-CLI
- How it works The rule is written with the
waf fw-rules addcommand; the fields are the same as in the form in the interface. - Where it is opened WEB-CLI →
waf host-groups list·waf fw-rules add·waf fw-rules list - Requirement WEB-CLI access; WAF protection enabled on the vService
- vService type HTTP vService with WAF protection enabled
Step-by-Step Configuration
The ID of the host group that the rule will go to is read from the list; the ID of the default group is defaultHost (waf host-groups):
waf host-groups list poolId <vService>The example is an exact rule that allows only POST for /api/v1/login and puts the path into signature scanning (required fields):
waf fw-rules add poolId <vService> hostGroupId <group> --path.input /api/v1/login --allowedMethods.type multiple --allowedMethods.input.0 POST --argOwasp trueA path that contains a wildcard is written in single quotes (e.g. --path.input '/api/v*/login') and becomes a glob rule on its own (request path). In WEB-CLI, only GET, HEAD, OPTIONS, POST, PUT, PATCH, DELETE, TRACE and CONNECT can be selected for --allowedMethods.input.N. The command gives no output when it succeeds.
waf fw-rules list poolId <vService> hostGroupId <group>Verification
The rule list is fetched again.
Command: waf fw-rules list poolId <vService> hostGroupId <group>
The /api/v1/login rowCommon Mistakes
- Putting
/at the end of an exact path. Since the trailing/character of the request path is dropped, the/api/login/exact rule does not match the/api/login/request;/api/loginis written. - Not paying attention to uppercase and lowercase. The matching is case-sensitive; the
/Loginrule does not match the/loginrequest. - Expecting Check fields to be defined in the form. Field inspections are added from the tabs of the detail panel after the rule is added.
- Thinking that an exact rule will inherit a method limit from Any paths. Path settings are not inherited; if the rule is added with Any Methods, there is no method restriction on that path (If a request matches more than one page type, how are the rules applied (exact path priority, glob rules merged with Any Paths)?).
- Leaving OWASP unchecked and thinking that the path scanning continues. In a new rule, OWASP is unchecked by default; if it is not checked, the path scanning of Any paths is not applied to this path either.
How it is done in the documentation
