Is it better to disable a signature entirely or to add an OWASP exclusion?
Short answer
The default preference is the exclusion. OWASP Exclusions silences the signature only in a specific field or parameter of a page type rule; the signature continues to be scanned in the other fields and pages of the same vService. Setting the state of the signature to Disabled removes it from scanning across the whole of a vService (OWASP Rules) or of the device (Signature & Rule Library): no match is searched for, no record is produced, and it is not scanned in Learning mode either. The intermediate step is the Monitor state: the signature is scanned and recorded but is not added to the risk score, and therefore does not block a request on its own (State values). If the false positive comes from a single application flow, an exclusion is added. If the signature matches the same legitimate content everywhere in the vService, it is first set to Monitor in that vService, and if the records show that the signature is unnecessary, it is set to Disabled. Disabling across the device is selected only when it is seen that the signature collides with legitimate traffic in all applications. In the case where the signature causes a problem only in one request section (e.g. Query), the sections in which it is scanned can be narrowed with Edit; the score and scope of a custom rule defined in the global layer cannot be changed from the vService screen, only its state (Change State) is changed.
How Does It Work?
| OWASP Exclusions | Signature state: Monitor | Signature state: Disabled | |
|---|---|---|---|
| Scope | A single host group → a single page type rule → a single field or parameter | vService (OWASP Rules) or device (Signature & Rule Library) | vService or device |
| Scanning | Done; the match of the signature in the exclusion is ignored | Done; the match is recorded, not added to the score | Not done |
| Event Logs | The match is not seen | The match is seen; if it was triggered on its own, the decision is Not blocked — Below the blocking threshold in a host group in Blocking mode, and Not blocked — Monitor mode in one in Monitor mode | The match is not seen |
| In Learning mode | The exclusion is not applied; the match is seen in the learning record | Scanned | Not scanned |
| How it is done | Allow / Teach, Edit Corresponding Rule or the form of the rule | Change State or Edit (for a global custom rule, only Change State on the vService screen) | Change State or Edit (for a global custom rule, only Change State on the vService screen) |
| Reverting | Deleting from the form or Revert Learning | Change State → Enabled or Restore to Default | Same |
| Caution | If the number of exclusions of a field exceeds the Max. OWASP Exclusions value (default 25), the signature scanning of that field turns off (What does the "Max. Owasp Exclusions" setting do; what happens if the limit is exceeded?) | - | All the fields the signature protects remain unprotected in that scope |
The signature library is layered: the state in the vService layer overrides the state in the global layer only for that vService (What are the rule layers (built-in library, global layer, vService layer); which one takes precedence?). Exclusions, on the other hand, always belong to the host group and page type rule of a vService; there is no device-wide exclusion list.
There are two more intermediate ways:
- Narrowing the scanning section: In the signature's Edit window, Inspection Scopes = Change is selected and the section causing the problem (e.g. Query) is removed; the signature continues to be scanned in the other sections. A custom rule defined in the global layer cannot be saved with Edit on the OWASP Rules screen of the vService; its score and scope are edited on the Signature & Rule Library screen, and only Change State is used in the vService.
- Lowering the score: If the risk score of the signature is lowered, its match contributes less to the accumulation. Since signatures with a Low score trigger only at the Aggressive protection level, pulling the score to Low effectively disables the signature at the other levels (Can I change a signature's score (Low / Medium / High / Very High)?).
Options in TR7
- Exclusion: Allow / Teach or Edit Corresponding Rule from the Attacks tab of the Event Logs record (How do I allow a request that was blocked by mistake?); at the parameter level: Can I turn off OWASP scanning for a specific parameter?
- Monitor or Disabled in the vService: Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → OWASP Rules on the signature summary strip → the signature is selected → Change State → New State → Accept (Can I disable a signature on a single vService only, rather than device-wide?).
- Across the device: The TR7 logo at the bottom left → Configuration Menu → WAF → Signature & Rule Library → the signature is selected → Change State (How do I fix the same false positive on several vServices at once (global layer)?).
- Following Monitor: The records of a signature set to Monitor are filtered in Event Logs with the Signature tab of the filter strip; if the records come only from legitimate requests, the signature can be set to Disabled (How do I try a new signature in production without risk (Monitor state)?).
Common Misconceptions
- "Disabling the signature requires less maintenance." Disabling removes the protection of the signature in all fields; the exclusion silences only the problematic field.
- "The Monitor state disables the signature." Scanning and recording continue; it is only not added to the score.
- "The Monitor mode of the host group and the Monitor state of the signature are the same." The mode of the host group determines whether all requests are blocked or not, and the signature state determines whether a single signature is included in the score or not.
- "In Learning mode, a signature with an exclusion is not seen." In Learning mode, exclusions are not applied; the exclusion is effective in the Monitor and Blocking modes.
How it is done in the documentation
