Are cookies scanned?
Short answer
Yes. Cookies are not a separate scope: the Cookie header is scanned like the other headers with the signatures that have Header in their Inspection Scopes list; the header name and the entire Cookie value are searched as a single value, without URL decoding. The Any Paths rule of every host group comes with a ready-made argument rule for the cookie header (Default Header Rules): in this rule, OWASP Check is on, the value must be at least 3 characters long and the header can be present at most once in the request. Cookie scanning is narrowed by turning off OWASP check in this rule or by adding specific signatures to the OWASP Exclusions list; for a single page type, the same setting is made by adding a separate argument rule for cookie in that page type. On the Signature & Rule Library screen, there is no option specific to cookies.
How Does It Work?
| Behavior | |
|---|---|
| Scope | Header (HTTP Headers in the list) |
| Scanned value | The header name (cookie) and the entire Cookie value; the value is not split into cookies, and no URL decoding is done |
| Default rule | Any paths → Header tab → cookie: OWASP Check on, Header Value Length ≥ 3, Header Value Count 1 |
| Record | On the Attacks tab of the Event Logs preview, the attack area is Header@cookie; which cookie triggered it is read from the matched content |
- The default header rules cover 21 headers; OWASP Check comes off in the
authorizationandrefererrules and on in the others, includingcookie(What are the default header rules?). - While the host group is in Learning mode, all headers are scanned regardless of the OWASP Check setting.
- Turning off only the signature scanning does not turn off the length and repetition inspections of the cookie; these are separate fields of the same rule.
Narrowing Cookie Scanning
For All Pages (Any paths)
In the Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab, the N page types row of the host group is clicked; the Page Types tab opens (accessing the screen).
The italic Any Paths row in the list is clicked; the detail panel of the rule opens on the right.
Header is clicked on the tab strip of the panel (accessing the Header tab).
In the Argument table below the common rule, the cookie row is clicked; the detail of the rule opens below the row.
Edit (pencil) above the detail is clicked; the form opens with the current values (argument rules).
To turn off signature scanning on the cookie entirely, the OWASP Check box is unchecked. To exclude only specific signatures, the box is left checked and the signatures are selected in the OWASP Exclusions field; the number of exclusions that can be selected is limited by the Max. OWASP Exclusions setting (What does the "Max. Owasp Exclusions" setting do; what happens if the limit is exceeded?).
The Edit button of the form is clicked; the change is applied without a separate deployment step. In a cluster setup, the change 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.
For a Single Page Type
In the Page Types list, the relevant page type is clicked and the Header tab is opened in the detail panel. If the page type has an exact path, the cookie row appears in italic: the rule is inherited from Any paths and cannot be edited here. In a page type with a glob path, the inherited rows are not shown in the list.
Add Argument Rule for Header above the Argument table is clicked. The form opens filled with the Header values of the Any paths rule.
cookie is written in the Argument Name field. OWASP Check is turned off, or it is left checked and the signatures to be excluded are selected in the OWASP Exclusions field. If needed, the length and repetition limits are kept the same as in the Any paths rule (Header Value Length ≥ 3, Header Value Count 1).
The Add button of the form is clicked. In this page type only, the rule takes the place of the cookie rule in Any paths.
For verification, a request that carries a value matching the signature in its cookie is sent, and whether there is a record with the Header@cookie area in Event Logs is examined; no record is created for a signature that is turned off or excluded.
Common Misconceptions
- "Every cookie is inspected separately." The value of the Cookie header is scanned as a whole.
- "Cookie signatures are listed separately in the library." The signatures that catch cookies are the signatures that have Header in their Inspection Scopes list; there is no separate cookie category.
- "The italic cookie row in the page type is edited from there." The inherited row is edited only from the Any paths rule it comes from; for a setting specific to the page type, a separate argument rule is added.
How it is done in the documentation
