How do I assess whether a false positive fix creates a security gap?
Short answer
The assessment is made before, during and after the fix. First, in the Attacks tab of the WAF Event Logs record, it is checked whether the section highlighted in Description is really the application's own data; then the scope of the change (a single parameter, one field of the page or the whole site through Any Paths) and its type are read from the Corresponding Rule and Learning Suggestion rows. The will be disabled suggestion turns off a value pattern or a block switch entirely; the New rule will be created note shows that a new rule will be opened for the path of the request. During the fix, the scope is narrowed: only the false positive attack is taught from the Attacks tab, and before a signature is disabled, it is put into the Monitor state. Afterwards, the exclusion count of the field in the detail panel of the page type rule, the vService-specific changes on the OWASP Rules screen and the changes written in red in the Description column (removing a value from a required list or turning off an inspection) in the AI Learning & Teacher Tracking history are examined; it is verified that the same attack, sent to a parameter outside the exclusion, is still blocked. An erroneous learning is undone with Revert Learning. An overlooked risk: if the exclusion count of a field exceeds the Max. OWASP Exclusions value (default 25), the signature scan of that field turns off without a warning.
How Does It Work?
A false positive fix changes the rule; its effect applies not only to that request but to all requests that come to the same rule and field. There are three things that determine the risk:
| Factor | Narrower (less risk) | Wider (more risk) |
|---|---|---|
| Scope | The argument rule of the parameter | The common rule of the field → Any Paths (all pages that have no rule of their own for this field) |
| Change type | will be marked as OWASP exclusion (a single signature) | will be added / will be updated (the list or the methods widen) → is <old> now and will be <new> (the limit grows) → will be disabled (the inspection turns off entirely) |
| Method | Exclusion | The signature's Monitor state on the vService → Disabled on the vService → Disabled on the global layer |
Teachings in the header field are always written to the Any Paths rule; that is, they apply to the host group as a whole (Which rule changes in the background when I Allow / Teach (Learning Suggestion)?).
The new exact rule opened by the teaching operation keeps on itself the path settings it copied from Any Paths (allowed methods, path depth, the OWASP settings of the path) and the copied field inspection; tightenings made later in Any Paths are not reflected in these settings. If the reason for the rule has disappeared, Revert Learning deletes the rule as well (if the rule has not been changed since then).
Checklist in TR7
| When | What is checked | Where |
|---|---|---|
| Before | Is the highlighted section the application's own data; if Detailed log disabled is written, the matching content was not written to the record and there is no evidence | Event Logs → record → Attacks tab; the Detailed Log setting of the field |
| Before | The scope and type of the change; the New rule will be created or Existing rule will be extended note | Corresponding Rule, Learning Suggestion |
| During | Was only the false positive attack selected; was an attack-based filter (Signature) used in collective teaching | Attacks tab, filter strip (Can I Allow / Teach several logs at once; are attacks hidden by the filter taught as well?) |
| During | Was the Monitor state tried before the signature was disabled; is the vService layer enough instead of the global layer | Is it better to disable a signature entirely or to add an OWASP exclusion? |
| After | Has the exclusion count of the field approached the Max. OWASP Exclusions limit | Page Types → rule → detail panel → the OWASP Check row of the field (✓ and the exclusion count) (What does the "Max. Owasp Exclusions" setting do; what happens if the limit is exceeded?) |
| After | vService-specific signature changes | OWASP Rules → the Customizations group in the Filter window; Original Rule / Edited Rule in the preview (If I change a built-in signature's score, state or scan scopes, how do I see the original (Original Rule / Edited Rule)?) |
| After | Is the evidence the automatic learnings rely on from a single client; is there a change written in red in the Description column (removing a value from a required list or turning off an inspection) | AI Learning & Teacher Tracking → AI Learning History / Teacher History (How do I see what AI Learning and Teacher applied in the past?) |
| After | Is the same attack still blocked on a parameter or page outside the exclusion | Test request → Attack blocked in Event Logs (Action values) |
| If needed | Undoing the erroneous learning | The WAF - WAAP Data Flow Panel on the right of the Dashboard or WAF Management tab → Log tab → learning record → Revert Learning (full permission in the WAF area is required) (Can I revert a learned rule?) |
If AI Learning is on, the thresholds and filters are reviewed against the risk of teaching attack traffic that appears widespread (Can an attacker fool AI Learning by making their traffic look widespread; how is this risk reduced?).
Common Misconceptions
- "Teaching releases only that request." It changes the rule; all requests that come to the same rule and field are affected.
- "Even if exclusions accumulate, the signature scan continues." When the exclusion count of a field exceeds the limit, the signature scan of that field turns off; the exclusions continue to appear in the rule.
- "Revert Learning undoes all fixes." Only the operations that leave a learning record (Allow / Teach, Teacher, AI Learning) are undone; manual rule edits and applied Analysis & Learning analyses are not undone.
- "A header false positive is fixed only for that page." Header teachings are written to the Any Paths rule, that is, to the host group as a whole.
How it is done in the documentation
