Can I turn off OWASP scanning for a specific parameter?

Short answer

Yes; the scanning can be turned off at two levels of granularity. If the OWASP Check box is unchecked in an argument rule specific to the parameter, the name and all the values of the parameter are excluded from signature scanning entirely; if the box is left on and only the signatures that produce false positives are added to the OWASP Exclusions list, the other signatures continue to be scanned, and this is the recommended way. Both settings are applied only to that parameter. The same exclusion is also added by selecting the attack in Event Logs and teaching it with Allow or Teach. If the number of exclusions defined for a parameter or section exceeds the Max. OWASP Exclusions value (default 25), the signature scanning of that parameter or section is not applied. In the Learning mode, scanning is done on every parameter; these settings are valid in the Monitor and Blocking modes.

Problem: A Parameter Constantly Produces False Positives

A parameter that carries free text, a code snippet or encoded data (a comment field, a search box, template content) triggers signatures and legitimate requests are blocked. The signature needs to be silenced only on this parameter, without turning it off on the whole site.

Solution: Four Methods

The methods are alternatives to each other; one is selected for the same parameter.

Your situation	Suitable method
Only specific signatures produce false positives on the parameter	Method 1: OWASP exclusions
The content of the parameter must not be scanned at all	Method 2: OWASP check off
I want to teach the false positive from the record	Method 3: Teaching from Event Logs
I want to turn off the scanning from the command line	Method 4: WEB-CLI

Method 1: OWASP Exclusions Recommended

• How it works The signatures selected in the argument rule of the parameter are skipped; the other signatures continue to be scanned.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → N page types → rule → tab → Add Argument Rule for …
• Requirement The number of exclusions does not exceed the Max. OWASP Exclusions value
• vService type WAF-enabled HTTP vService
• Sections Query, Header, JSON, Xml, Form; in the Path and Raw tabs, exclusions are written to the common rule

Step-by-Step Configuration

1

Adım 1 Open the Page Types list

In the Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab, the N page types row of the host group is clicked (accessing the Page Types screen).

2

Adım 2 Select the page type

The page type of the path the parameter comes in is clicked; the detail panel opens on the right (accessing the panel). Which rule is applied is seen in the Corresponding Rule row on the Attacks tab of the Event Logs record.

3

Adım 3 Open the tab

The tab of the section where the parameter is located (e.g. Query) is clicked.

4

Adım 4 Open the argument rule form

Add Argument Rule for … above the variable table is clicked. If the parameter already has its own argument rule (a bold row in the table), the row is clicked and Edit is used. The form opens filled with the common values of the Any paths rule in that section.

5

Adım 5 Enter the name

The name of the parameter is written in the Argument Name box (e.g. comment).

6

Adım 6 Select the signatures

OWASP Check is left checked; the signatures that produce false positives are selected from the OWASP Exclusions multiple selection that appears below it. The name and ID of the signature are seen on the Attacks tab of the Event Logs record (Attack Name, Attack ID). The other value fields in the form (… value length, … value count, … value pattern) also become valid for this parameter; a field left empty means no restriction for that inspection.

7

Adım 7 Save

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.

Verification

1Detail panelTR7 side

The row of the parameter in the variable table is clicked and the OWASP check row is looked at.

Expected✓ and the number of exclusions next to it

2Repeat requestClient side

A request is sent with the same value that produced the false positive and the Event Logs list is checked.

ExpectedNo new record for the selected signature

Method 2: OWASP Check Off

• How it works The name and values of the parameter are not scanned with any signature; the structural inspections (length, pattern, repetition) continue.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → N page types → rule → tab → Add Argument Rule for …
• Requirement Restricting the content of the parameter with other inspections (e.g. … value pattern) is recommended
• vService type WAF-enabled HTTP vService

Step-by-Step Configuration

1

Adım 1 Open the argument rule form

The argument rule form of the parameter is opened with steps 1–4 in Method 1.

2

Adım 2 Enter the name

The name of the parameter is written in the Argument Name box.

3

Adım 3 Uncheck OWASP check

The OWASP Check box is unchecked; the OWASP Exclusions field is removed from the form.

4

Adım 4 Save

Add (Edit when editing) is clicked.

Verification

1Detail panelTR7 side

The row of the parameter in the variable table is clicked and the OWASP check row is looked at.

Expected-

Method 3: Teaching from Event Logs

• How it works The false positive record is taught; the signature is written as an exclusion to the argument rule of the parameter if there is one, and otherwise to the common rule of the section. If Rule Creation Policy requires it, the teaching creates a new page type; the result is seen beforehand in the Learning suggestion row.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs → record → Attacks tab
• Requirement The record must have been produced in the Monitor or Blocking mode
• vService type WAF-enabled HTTP vService
• Scope difference If there is no argument rule specific to the parameter, the exclusion is written to the common rule and covers all the parameters in the section; if it is to cover only one parameter, an argument rule is first opened with Method 1

Step-by-Step Configuration

1

Adım 1 Open the Event Logs screen

In the Left Monitor Panel → WAF-Protected vServices → vService, the Event Logs tab is opened.

2

Adım 2 Open the record

The row of the false positive record is clicked; the preview window opens.

3

Adım 3 Mark the attack

On the Attacks tab, the box at the start of the row of the attack to be taught is checked; the Learning suggestion row shows which rule the exclusion will be written to.

4

Adım 4 Teach

The Allow (in a blocked record) or Teach (in a monitored record) button above the table is clicked. Details: How do I allow a request that was blocked by mistake?

Verification

1Attacks tabTR7 side

The Attacks tab of the same record is checked again.

ExpectedLearning suggestion: Already learned

Method 4: WEB-CLI

• How it works The argument rule of the parameter is added with WEB-CLI by giving --argOwasp false.
• Where it is opened WEB-CLI → waf rule-parts add
• Requirement WEB-CLI access
• vService type WAF-enabled HTTP vService
• Pre-fill differenceadd writes the command's defaults to the fields that are not written; valueLength comes as 0–1024 and is changed in the command for parameters that carry long values. Signature exclusions (OWASP exclusions) are added from the interface or from Event Logs.

Step-by-Step Configuration

1

Adım 1 Find the rule ID

The ID of the default host group is defaultHost; rule IDs are listed in the id column:

waf fw-rules list poolId <vService> hostGroupId defaultHost

2

Adım 2 Add the argument rule

An argument rule without scanning is added with the value length limit removed. If there is a rule with the same name, the command is rejected; in that case, the ID of the part is found with waf rule-parts list and update … id <part> --argOwasp false is used:

waf rule-parts add poolId <vService> hostGroupId defaultHost ruleId <rule> loc query --arg comment --argOwasp false --valueLength.op none

Verification

1Part listTR7 side

The parts of the rule are listed.

Command: waf rule-parts list poolId <vService> hostGroupId defaultHost ruleId <rule>

Expectedquery: comment

Common Mistakes

• Turning off OWASP check for the whole section. Unchecking the box in the common rule leaves all the parameters in the section that do not have their own argument rule out of scanning; the setting is made only in the argument rule of the problematic parameter.
• Overlooking the other value fields in the argument rule. For that parameter, the argument rule replaces the value inspections of the common rule; a … value count or … value length left empty removes that limit (How do inheritance and "Rule Source" work in rules?).
• Testing in the Learning mode and saying "it still triggers". In the Learning mode, signature scanning is done on all parameters without exception and the hits are written to the learning record; the effect of the exclusion is seen in the Monitor or Blocking mode.
• Exceeding the Max. owasp exclusions limit. If the number of exclusions on a parameter or section exceeds the limit, the signature scanning of that parameter or section is not applied (What does the "Max. Owasp Exclusions" setting do; what happens if the limit is exceeded?).
• Turning off the signature on the whole site. When an exclusion for a single parameter is enough, turning off the signature affects all paths (Is it better to disable a signature entirely or to add an OWASP exclusion?).

How it is done in the documentation

• Query · OWASP Check
• Query · OWASP Exclusions
• OWASP Protection Level · Max. OWASP Exclusions
• Event Logs · Attacks Tab

Related questions

• How do I allow a request that was blocked by mistake?
• Is it better to disable a signature entirely or to add an OWASP exclusion?
• How do inheritance and "Rule Source" work in rules?