Can I define required parameters (Required Query Parameters / Required Headers / Required Form Fields)?
Short answer
Yes. In the common rule on the Query, Header and Form tabs of the page type, there are the Required Query Parameters, Required Headers and Required Form Fields lists; when the list is set to the Restrict position and names are added, every name that is not present in the request produces a separate 24-point violation in the Structure Policies category. It is enough that the name be present in the request; its value may be empty. In a request that has no query string at all, all the required query parameters count as missing; Required Form Fields is inspected only in requests that carry a form body. Header names are written in lowercase. In the JSON and Xml sections, there is no required name list. For the inspection, Argument Checks must be on in the Checks window.
Problem: Requests That Come Without a Required Field Reach the Application
An endpoint should be called only with a certain query parameter, header or form field (e.g. an API key header, a CSRF field); if the field is missing, the request should be rejected before it reaches the application.
Solution: Two Methods
The two methods write the same list; one of them is selected.
| Your situation | Suitable method |
|---|---|
| I want to make the setting from the interface | Method 1: Required list in the common rule |
| I want to do it with a script or the command line | Method 2: WEB-CLI |
Method 1: Required List in the Common Rule Recommended
- How it works A required name list is written to the common rule of the section; every name that is not present in the request counts as a separate violation.
- Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → N page types → rule → Query / Header / Form → Add Common Rule for …
- RequirementArgument Checks on
- vService type WAF-enabled HTTP vService
- Area of effect Only the requests that match this page type; a list written to the Any paths rule is applied to all the paths that do not have their own common rule for that section
Step-by-Step Configuration
Argument Checks comes on when WAF is turned on; if it has been turned off, in the Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab, the pencil icon at the top right of the Checks card in the Inspection & Blocking section is clicked (Checks Edit screen).
Argument Checks is turned on.
Edit is clicked.
On the WAF Management tab, the N page types row of the host group is clicked (accessing the Page Types screen).
The row of the page type is clicked in the list; the detail panel of the rule opens on the right (accessing the panel). If there is no page type, it is added first (How do I add a new page type manually?).
According to the type of the required name, the Query, Header or Form tab is clicked.
Add Common Rule for Query (or … for Header, … for Form) above the table is clicked; if the rule has its own common rule for that section, the button appears as Edit Common Rule for …. The add form opens filled with the values of the Any paths rule in that section.
The Required Query Parameters, Required Headers or Required Form Fields switch is set to the Restrict position and every name is added to the list as a separate item:
| Section | Spelling of the name |
|---|---|
| Query | In its raw (URL-encoded) form in the request, case-sensitive |
| Header | In lowercase (x-api-key); headers are compared after being lowercased, list entries are not converted |
| Form | In its raw form in a urlencoded body, with the name value of the field in a multipart body; case-sensitive |
Add (Edit when editing) is clicked; the change is applied without a separate deployment step. In a cluster setup, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent to the peer device manually. To remove the requirement, the field is set to the No Restriction position.
Verification
While the host group is in Blocking mode, a request is sent without the required header; then it is repeated with the header.
Command: curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/api/rapor
418 for the request without the header, the application's response for the request with the headerOn the Event Logs screen of the vService, the record is selected and the Attacks tab is checked.
Attack area: Header@x-api-key · Attack name: Required headersMethod 2: WEB-CLI
- How it works The required name list is written to the common part of the rule with WEB-CLI (
queryMustArgs,headerMustArgs,formMustArgs). - Where it is opened WEB-CLI →
waf rule-parts - Requirement WEB-CLI access; Argument Checks on (
waf options update poolId <vService> --syncWithDefaultFwRules false --argumentChecks true) - vService type WAF-enabled HTTP vService
- Pre-fill difference The
addcommand writes the command defaults, not the Any paths values, to the fields that are not written
Step-by-Step Configuration
The ID of the default host group is defaultHost; rule IDs are listed in the id column (the Any paths rule appears as default rule):
waf fw-rules list poolId <vService> hostGroupId defaultHostThe row that shows header: (all keys) (or query: …, form: …) in the description column is the common part of that section:
waf rule-parts list poolId <vService> hostGroupId defaultHost ruleId <rule>The headerMustArgs.0, headerMustArgs.1 … lines in the output are the existing required names:
waf rule-parts show poolId <vService> hostGroupId defaultHost ruleId <rule> <part>--headerMustArgs.N replaces the existing name at that position; the new name is written to the first empty position (0 if the list is empty):
waf rule-parts update poolId <vService> hostGroupId defaultHost ruleId <rule> id <part> --headerMustArgs.0 x-api-keyadd writes the command defaults to the fields that are not written: in Header, headerSize at most 4096 and headerKeyCount at most 32; in Form, formBlockAll and formBlockInvalid on and formKeyCount at most 32; in both sections, valueLength 0–1024 (region fields). When a form part is added, --formBlockAll false is given so that all form bodies are not blocked:
waf rule-parts add poolId <vService> hostGroupId defaultHost ruleId <rule> loc form --formBlockAll false --formMustArgs.0 csrfVerification
The part is displayed again.
Command: waf rule-parts show poolId <vService> hostGroupId defaultHost ruleId <rule> <part>
The required names in the headerMustArgs linesCommon Mistakes
- Writing the required header to the Any paths rule. The Header common rule of the Any paths rule is applied to all the paths that do not have their own Header rule; external monitoring services and non-static requests from the browser are also blocked because they do not carry the header. The requirement is written to the path-specific page type.
- Writing the header name in uppercase. Headers are compared after being lowercased, list entries are not converted;
X-Api-Keyis never satisfied (Can I require a specific header to be present?). - Thinking that Required form fields inspects GET requests as well. The inspection runs only in requests whose
application/x-www-form-urlencodedormultipart/form-databody is parsed; a request without a body does not produce a violation from this list. - Looking for a required key for a JSON API. In the JSON and Xml sections, there is no required list; the shape of the body is restricted with Allowed JSON Keys and argument rules (Can I allow only specific keys in JSON; how are nested key paths written?).
- Adding the form part with
addwith the defaults in WEB-CLI. TheformBlockAlldefault is on; if--formBlockAll falseis not given in the command, all form bodies that come to the page are blocked.
How it is done in the documentation
