Should I fix a false positive for a single parameter only or for the whole page?

Short answer

It is fixed in the narrowest possible scope. The Query, Header, JSON, XML and Form fields of a page type rule have two layers: the common rule is applied to all the parameters in the field, and the argument rule only to the single parameter whose name is given. Allow / Teach selects the target itself: if there is an argument rule for that parameter, it writes the exclusion there, and if there is not, to the common rule of the field; if the matching rule is Any Paths, the change is written to the new rule opened for the path of the request if the Rule Creation Policy covers the field, and to Any Paths if it does not. Learning does not open a new argument rule; for the exclusion to be narrowed down to only a single parameter, the argument rule of that parameter is added first, and then Allow / Teach is done or the exclusion is entered manually in the form of the rule. If the false positive comes from the data of a single field (comment, description, HTML editor), the parameter level is selected, and if many fields of the same form produce the same signature, the common rule level is selected. If the signature matches the same legitimate content on every page of the vService, setting the signature to Monitor on the OWASP Rules screen of the vService instead of adding an exclusion is easier to track. If the number of exclusions of a field exceeds the Max. OWASP Exclusions value (default 25), the signature scanning of that field turns off without a warning; piling exclusions onto a broad rule is risky for this reason.

How Does It Work?

Source of the false positive	Scope	Effect of the exclusion
The data of a single parameter (e.g. comment)	Argument rule	Only that parameter; the other parameters continue to use the exclusion list of the common rule (OWASP Exclusions)
Many fields of the form on the same page	The common rule of the page type rule	All the parameters of the field on that page
The same field on many pages	The common rule of the Any Paths rule	All the pages that do not have their own rule for this field
The same content everywhere in the vService	OWASP Rules → Monitor	The signature is scanned and recorded in this vService but is not added to the score (Is it better to disable a signature entirely or to add an OWASP exclusion?)

When the argument rule of a parameter is defined, the value inspections of that parameter (value length, value pattern, repetition count, OWASP Check) are taken entirely from this rule; the value inspections of the common rule are no longer applied to that parameter (Argument Name). When the argument rule is being added, the form comes filled with the values of the common rule; if the fields are emptied, that inspection is removed for the parameter. The structural inspections that belong to the field as a whole, such as the number of parameters and the key length, are not affected by the argument rule and are always written to the common rule in teaching. The field inspections the rule does not define are inherited from the glob rule or from Any Paths (How do inheritance and "Rule Source" work in rules?).

Viewing and Narrowing the Scope in TR7

• Seeing the target: In the Attacks tab of the Event Logs record, the Corresponding Rule row shows the path of the target rule; if there is an Argument row below it, the target is the argument rule of that parameter, and if there is not, it is the common rule of the field. If Any Paths is seen as the path and there is no New rule will be created below the suggestion row, the change is written to Any Paths (Which rule changes in the background when I Allow / Teach (Learning Suggestion)?).
• Narrowing to a single parameter: With WAF Management → N page types on the mode card → rule → the tab of the field → Add Argument Rule for <field>, an argument rule is added for the parameter and the parameter name is written in the Argument Name field (argument rules). Then Allow / Teach is done from Event Logs or the exclusion is entered manually in the OWASP Exclusions list in the same form; step-by-step description: Can I turn off OWASP scanning for a specific parameter?
• Tracking the number of exclusions: In the detail panel of the rule, the number of exclusions is seen next to the ✓ mark in the OWASP Check row of the field; the limit is the Max. OWASP Exclusions field in the window opened with the pencil icon of the OWASP Protection Level card in the Inspection & Blocking section in WAF Management (What does the "Max. Owasp Exclusions" setting do; what happens if the limit is exceeded?).

Common Misconceptions

• "Allow / Teach always writes to that parameter." If the parameter has no argument rule, it writes to the common rule of the field; the exclusion becomes valid for all the parameters in the field.
• "Adding an argument rule also adds that parameter to the allowed list." Defining an argument rule does not by itself add the parameter name to the allowed parameters list.
• "The number of exclusions is unlimited." When the limit is exceeded, the signature scanning of that field turns off entirely; the values continue to be seen in the rule but are not applied.

How it is done in the documentation

• Path Check Fields · Two Layers: The Common Rule and the Argument Rule
• Query · The Add Argument Rule for Query Screen
• Learning Methods · What Is Learning Methods?

Related questions

• Can I turn off OWASP scanning for a specific parameter?
• How do inheritance and "Rule Source" work in rules?
• Is it better to disable a signature entirely or to add an OWASP exclusion?