What is the "Inspection Scopes" field for when adding a custom rule?

Short answer

Inspection Scopes selects in which sections of the request the pattern will be searched for: Path, Query, Header, Form, JSON, XML and Raw. At least one scope must stay selected; in the Add Custom Rule window, only Path is checked by default. Every selected scope counts as a separate signature and the pattern is scanned separately against the content of that section; in a section that is not selected, the pattern is not searched for at all. Selecting unnecessary scopes increases both the number of signatures and the inspection cost per request; for a pattern that is meaningful only in the query parameters, Query is enough. The selected scopes appear in the list as a number in the Signatures column, and in the preview in the Active Signature Fields row with the names URI Path, Query String, HTTP Headers, Form Data, JSON Body, XML Body and Raw Body. The scopes of a built-in signature can also be narrowed in the Edit Rule Changes form; this is the way to take the signature out of the section in which it produces false positives without turning it off. A scope change does not require the signature database to be recompiled.

How Does It Work?

What the pattern targets	Scope to select (its name in the form)
A pattern in the request path	Path
The name or the value of a query parameter	Query
A header value, including Cookie	Header
An application/x-www-form-urlencoded or multipart form field	Form
A key or a value in a JSON API body	JSON
An element name or a value in an XML/SOAP body	XML
A body that cannot be parsed, the whole of a multipart body, uploaded file content	Raw

• What is scanned in each scope: In which parts of a request are signatures scanned (Path, Query, Header, JSON, XML, Form and Raw)?
• Whether a section is really scanned also depends on the OWASP Check setting of that section being on in the page type the request matches; the scope selection does not override this setting.
• The switch at the beginning of the scope list checks or unchecks all the scopes at once; the list cannot be emptied.

Narrowing the Scope of a Built-in Signature

1

Adım 1 Select the signature

According to the layer in which the signature will change, Signature & Rule Library (all vServices) or the OWASP Rules screen of the vService (only that vService) is opened and the row of the signature is checked.

2

Adım 2 Open the edit form

Edit on the toolbar is clicked; the Edit Rule Changes window opens.

3

Adım 3 Change the scopes

The Inspection Scopes switch is moved from the Keep Original position to the Change position; the list opens with the current scopes of the signature. The check of the section that produces false positives is removed (e.g. Query from a signature that works correctly in the body but matches unnecessarily in the query string). The State and Score switches are left at Keep Original.

4

Adım 4 Save

Accept is clicked; the change is applied without a deployment step and without recompiling. 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.

After the save, the row appears in italic and in a yellow tone, and the number in the Signatures column decreases; in the preview, the Original Rule and Edited Rule columns come side by side and the Active Signature Fields row is highlighted. The scope change is counted as Changed in the Filter → Customizations group.

Common Misconceptions

• "Selecting all the scopes is safer." Each scope means a separate scan; in the sections where the pattern is not meaningful, false positives and the cost increase.
• "A scope change requires recompiling." Only a pattern change and a new custom rule require compiling; state, score and scope changes are applied without compiling.
• "Narrowing the scope and OWASP exclusions are the same thing." Narrowing the scope takes the signature out of that section on all pages; OWASP exclusions are valid only in the section or the parameter in the selected page type (Is it better to disable a signature entirely or to add an OWASP exclusion?).

How it is done in the documentation

• Signature & Rule Library · Inspection Scopes (Add Custom Rule)
• Signature & Rule Library · Inspection Scopes (Edit Rule Changes)
• Signature & Rule Library · The Distinction Between the Signature and the Pattern

Related questions

• In which parts of a request are signatures scanned (Path, Query, Header, JSON, XML, Form and Raw)?
• What is Check Fields; into which seven parts does the WAF split a request to inspect it?
• Is it better to disable a signature entirely or to add an OWASP exclusion?