How does tightening the protection level affect false positives?
Short answer
As the OWASP Protection Level is tightened (as the number gets smaller: Elementary 24 → Aggressive 2), the score needed to reach the threshold drops; since fewer hits are enough, the odds of clean traffic being blocked by mistake increase. The card shows these odds as very low for Elementary, Normal and Tight, low for Very tight and high for Aggressive. Switching to Aggressive also brings into play the signatures with a Low score that are not scanned at all at the other levels; for this reason, the biggest increase is in the Very tight → Aggressive step. As the threshold drops, the number of records written to Event Logs increases as well. False positives caused by structural violations (24 points) are not affected by the level; these and signature-caused false positives are eliminated without touching the level, with the signature state, OWASP Exclusions or Allow / Teach.
How Does It Work?
| Level | Threshold | Signatures that reach the threshold with a single hit | Low signatures | Odds on the card |
|---|---|---|---|---|
| Elementary | 24 | None | Not scanned | very low |
| Normal | 16 | None | Not scanned | very low |
| Tight | 8 | Very High | Not scanned | very low |
| Very Tight (default) | 4 | Medium, High, Very High | Not scanned | low |
| Aggressive | 2 | All signatures, including Low | Scanned | high |
- Threshold effect: At a tight level, a single legitimate request being caught by a Medium signature is enough to reach the threshold; at a loose level, the same request passes. The effect is most pronounced in signatures with a low Score value.
- Low signatures: At the levels other than Aggressive, Low signatures are not scanned at all; at Aggressive, they are scanned and each of them reaches the threshold on its own. On the OWASP Rules screen of the vService, which signatures have been disabled because of the level is seen with the
Low*mark. - Record volume: Only requests whose total reaches the threshold (and requests in which a signature in the Monitor state was triggered) are written to Event Logs; as the threshold drops, the number of requests that enter the record increases.
- Sync with default WAF rules: If Sync with Default WAF Rules is checked while the level is being set to Aggressive, the Any Paths rule is set up again with the tight set: the path length becomes at most 1024, the path depth at most 8, and the allowed methods only GET, OPTIONS and HEAD; JSON, XML and form bodies and file uploads are blocked, and if Argument Checks is on, the allowed parameter lists start empty (every parameter is counted as a violation) and the Host and User-Agent headers become mandatory. This set also counts legitimate requests that come with methods such as POST as structural violations; it is a false positive source separate from the level.
- Structural violations: Since 24 points reaches the threshold of every level, a level change neither increases nor decreases structural false positives.
Reducing False Positives Outside the Level
| Method | Effect | Where |
|---|---|---|
| Putting the signature into the Monitor state | The signature is recorded but does not take part in the total | OWASP Rules on the vService, Signature & Rule Library → Change State device-wide (What does a signature's state (Enabled / Monitor / Disabled) mean?) |
| Lowering the Score value of the signature | The signature adds fewer points | OWASP rules · Signature & Rule Library (Can I change a signature's score (Low / Medium / High / Very High)?) |
| Field-based exclusion | The signature is left unscanned only in the related parameter | Page type → Check Fields → OWASP Exclusions (Is it better to disable a signature entirely or to add an OWASP exclusion?) |
| Teaching the record | The related rule is updated so as to accept the request | Event Logs → Allow / Teach |
The effect of a level change can first be seen in Monitor mode: while the Virtual Host Group is in Monitor mode, the level is changed, the Not blocked — Monitor mode records in Event Logs are reviewed, and then a switch to Blocking mode is made (How do I use Monitor mode to weed out false positives?).
Common Misconceptions
- "A loose level fully prevents false positives." Structural violations (24) and blacklist hits (100) reach the threshold at every level.
- "Aggressive only lowers the threshold." Aggressive also runs the Low signatures that are not scanned at the other levels.
- "A loose level only reduces false positives." Real attacks that stay below the threshold also pass and are not written to Event Logs.
- "Switching to a tight level directly in Blocking mode is safe." Its effect is first followed in Monitor mode; false positives are seen without legitimate traffic being blocked.
How it is done in the documentation
Related questions
- Which protection level should I choose (Elementary, Normal, Tight, Very Tight and Aggressive)?
- In which cases is a request not blocked even though an attack is detected (signature in Monitor state, Monitor mode, Teacher, Learning mode)?
- How do I use Monitor mode to weed out false positives?
- I am blocking legitimate users by mistake; how do I find out?
