How do I allow a request that was blocked by mistake?

Short answer

The record of the blocked request is opened on the WAF Event Logs screen; on the Attacks tab of the preview, the Description field of every attack highlights the matched part of the request. Only the attacks that are false positives are checked and the Allow / Teach button above the table is clicked; the button takes the name Allow on a blocked record and Teach on a record that was monitored or let through by Teacher. The Learning Suggestion row writes the change to be made in advance: in a signature hit, the signature is added to the OWASP Exclusions list in the related field of the matched page type rule, and if there is an argument rule for that parameter, it is written there; in a structural violation, the related limit is widened; the signature is not turned off. After the Are you sure? confirmation, the change is applied without a separate deployment step and the same request is no longer blocked with today's rules. To determine the change manually, the form of the same rule is opened from the Page Types screen and the signature is added to the OWASP Exclusions list. If the signature conflicts with the same legitimate content on every page of the vService, its state is set to Monitor on the OWASP Rules screen of the vService. Learnings made with Allow / Teach are reverted with Revert Learning in the Log timeline.

Problem: A Legitimate Request Was Blocked

In Event Logs, it was seen that a legitimate request was blocked by WAF (How do I tell that a legitimate request was blocked by the WAF?). The same request must not be blocked again, while the rest of the protection must continue.

Solution: 3 Methods

Your situation	Suitable method
I want to teach the attack the record triggered in the narrowest scope	Method 1: Allow / Teach
I want to determine the exclusion or limit to be written myself	Method 2: OWASP Exclusions in the rule form
The signature conflicts with the same legitimate content everywhere in this vService	Method 3: OWASP Rules → Change State

Method 1: Allow / Teach Recommended

• How it works For the selected attack, the host group is found according to the Host value of the request and the page type rule according to its path, and the change is written to that rule (Which rule changes in the background when I Allow / Teach (Learning Suggestion)?). In a signature hit, the signature is added to the exclusion list of that field; the signature continues to work in the other fields and pages.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs tab → record → Attacks
• Requirement Modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Event Logs screen

The Left Monitor Panel → WAF-Protected vServices → vService → Event Logs tab is opened.

2

Adım 2 Pull the logs

In the server filter, Date Range is selected, if the record is known, the ID of the request is written in the Request Unique ID field, and Save & Get Logs is clicked.

3

Adım 3 Open the record

The row of the blocked request is clicked; the preview opens on the right.

4

Adım 4 Examine the attack

On the Attacks tab of the preview, an attack row is clicked. Description highlights the matched part of the request, Corresponding Rule shows the page type rule the change will be written to (with the parameter name, if any), and Learning Suggestion shows the change to be made. If the highlighted part is not the application's own data, the attack is real and is not taught. If the attack name appears green and the suggestion says Already learned, there is nothing left to teach.

5

Adım 5 Check the false positive attacks

In the Attacks table, only the boxes of the attacks that are false positives are checked. If a single attack is to be taught, its row can be left selected and the button in the detail block can also be used.

6

Adım 6 Teach

The button above the table is clicked; its name becomes Allow (blocked record) or Teach (record that was monitored or let through by Teacher) according to the decision of the record.

7

Adım 7 Confirm

In the Are you sure? window, Yes is clicked. The change is applied without a separate deployment step; there is no separate preview screen for the change. In a cluster, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.

The same teaching operation can also be started from other places; all of them write the same change, only the attacks they cover differ:

Entry point	Scope
Allow / Teach on the Event Logs toolbar	All visible attacks of the selected rows; if there is an attack-based selection (e.g. Signature) in the filter strip, only the ones that match the selection (Can I Allow / Teach several logs at once; are attacks hidden by the filter taught as well?)
The right-click menu of the row	Only the clicked row
The button in the preview title	All visible attacks of the previewed record
Global WAF Event Log	The selected rows of different vServices; every vService writes to its own rule set and the confirmation is asked separately for every vService

Verification

1Attacks columnTR7 side

The Attacks column of the taught row is checked; when it is hovered over with the cursor, the … of … would still be blocked by today's rules tip appears.

Expected0 / N · row pale green

The decision of the row does not change: the record shows the decision given in the past, while the column counts how many attacks the same request would produce with today's rules.

2Repeat of the requestClient side

The user is asked to repeat the same operation.

ExpectedThe application's response instead of the blocking page

Method 2: OWASP Exclusions in the Rule Form

• How it works The exclusion is written manually to the related field of the page type rule; which field and which signature are written is determined by the user. Edit Corresponding Rule in Event Logs opens the same form directly from the record (How do I edit the matching rule from a log with "Edit Corresponding Rule"?).
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → N page types on the mode card of the host group → rule → detail panel
• Requirement Modify permission in the WAF area; the Attack ID value of the signature in the Event Logs record and the Corresponding Rule information
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Page Types screen

In the Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab, the N page types row below the mode card of the host group the request falls into is clicked.

2

Adım 2 Select the rule

In the list, the rule written in the Corresponding Rule row of the Event Logs record is clicked; the detail panel of the rule opens on the right. If the record shows the Any Paths rule, the exclusion is applied to all pages that do not have their own rule for this field; if an exclusion is wanted for only one page, a rule is first added for that path (How do I add a new page type manually?).

3

Adım 3 Select the field's tab

In the detail panel, the tab of the field in which the attack was caught is selected: Path, Query, Header, JSON, Xml, Form or Raw.

4

Adım 4 Open the form

For all parameters of the field, Edit Common Rule for <field> (Add Common Rule for <field> if the rule has no inspection of its own in this field) in the upper table of the tab is clicked. For a single parameter only, the parameter's row is selected in the Argument table and Edit with the pencil icon is clicked; if the parameter has no rule, it is added with Add Argument Rule for <field> (Can I turn off OWASP scanning for a specific parameter?). On the Path tab, Edit in the panel title is used.

5

Adım 5 Select the exclusion

OWASP Check is left checked; in the OWASP Exclusions multiple selection that appears below it, the signature in the Event Logs record is selected. If the OWASP Check box is unchecked, the field is removed from the scanning of all signatures.

6

Adım 6 Save

The Edit button of the form (Add in a new rule) is clicked; there is no additional confirmation or deployment step. In a cluster, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.

Verification

1Detail panelTR7 side

In the detail panel of the rule, the OWASP Check row of the field is examined.

Expected✓ and the number of exclusions next to it

2Event LogsTR7 side

The Attacks column in the Event Logs row of the blocked request is checked.

ExpectedThe first number falls

Method 3: OWASP Rules → Change State

• How it works The state of the signature is changed only for this vService. A signature in the Monitor state is scanned and recorded but is not added to the risk score; a signature in the Disabled state is not scanned at all (Is it better to disable a signature entirely or to add an OWASP exclusion?).
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → OWASP Rules in the signature summary strip
• Requirement Modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the OWASP Rules screen

In the Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab, the OWASP Rules link in the signature summary strip is clicked; the rule view opens in a new tab (how to access).

2

Adım 2 Find the signature

The Attack ID in the Event Logs record or the name of the signature is written in the search box.

3

Adım 3 Open the Change State window

The row of the signature is selected and Change State on the toolbar is clicked.

4

Adım 4 Select the new state

New State = Monitor is selected; if the signature is definitely unnecessary on this vService, Disabled is selected. The field comes with Enabled at every opening.

5

Adım 5 Save

Accept is clicked; no separate confirmation window is displayed and the change is applied. Details: Can I disable a signature on a single vService only, rather than device-wide?

Verification

1Signature rowTR7 side

On the OWASP Rules screen, the State column of the signature is checked.

ExpectedMonitor · row colored

When a signature in the Monitor state is triggered alone, the request passes; if the host group is in Blocking mode, it is recorded in Event Logs with the "Not blocked — Below the blocking threshold" decision, and if it is in Monitor mode, with the "Not blocked — Monitor mode" decision.

Common Mistakes

• Teaching without reading the Description. If the highlighted part is not the application's own data, the record is a real attack; teaching it lets the attack through as well.
• Teaching the whole record. If there is also a real attack in the same request, the button on the toolbar teaches it as well; only the false positive attacks are checked from the Attacks tab.
• Overlooking the "will be disabled" suggestion. In a value pattern (regex) violation, teaching does not narrow the pattern but removes it entirely; to keep the pattern, the rule is fixed manually from the form in Method 2.
• Expecting the exclusion to work in a host group in Learning mode. In Learning mode, the signature scan does not apply the exclusions; the exclusion is effective while the group is in Monitor or Blocking mode.
• Piling unlimited exclusions on a field. If the number of exclusions of a field exceeds the Max. OWASP Exclusions value (default 25), the signature scan of that field turns off without a warning (What does the "Max. Owasp Exclusions" setting do; what happens if the limit is exceeded?).
• Trying to teach when the source should not be inspected at all. To keep a trusted source outside WAF, Whitelist Condition is used (Can I exempt certain IPs or requests from WAF inspection entirely (Whitelist Condition)?).

How it is done in the documentation

• Event Logs · Attacks Tab
• Event Logs · Allow / Teach
• Query · OWASP Exclusions
• AI Learning & Teacher Tracking · Reverting the Learning

Related questions

• Which rule changes in the background when I Allow / Teach (Learning Suggestion)?
• Can I turn off OWASP scanning for a specific parameter?
• Can I revert a learned rule?