Dealing with deny rules false positives

Sometimes, requests are blocked by deny rules due to content that resembles attacks but may actually be valid for a certain web application. These blocks are called false-positives. Usually, these kinds of blocks occur during integration or at an early stage after going live.

  1. By going through the following steps, the correct configuration can be found:
  2. Search the logs for block messages
  3. Resolve the false-positives
  4. Repeat until no unwanted block messages appear in the logs.

Search the logs for block messages

Block log messages are generally identified by a log_id starting with WR-SG-BLOCK*.

  • For deny rule blocks, search for:
  • WR-SG-BLOCK-110-01
  • WR-SG-BLOCKDET-110-*

Request summary log messages are always a good source of information and could be helpful to compose a deny rule exception. The table below shows how to combine the log information with the corresponding DSL setting to compose a deny rule exception.

Log message id

Log key

DSL key

Example log message














"message":"Blocked parameter: \"comment=..."

The WR-SG-BLOCKDET-* log messages are only logged in the integration log level.

Resolve the false-positives

After verifying that the blocked request was a false-positive, there are the following options to resolve this issue:

  • Add a deny rule exception for the blocking deny rule group.
  • To configure a deny rule exception, add the exceptions segment in the deny_rule_groups section of the mapping (see DSL reference).

      The example will add a deny rule exceptions for:

    • the parameter password on for all deny rule groups.
    • the parameter comment, on the path /contactform for the deny rule group HTML_PARAM_VALUE.
          - name: example
              value: /
              - exceptions:
                  - parameter_name:
                      pattern: ^password$
              - rule_group_keys:
                  - HTML_PARAM_VALUE
                  - path:
                      pattern: ^/contactform
                  - parameter_name:
                      pattern: ^comment$

    Check Deny rule exceptions to understand how Airlock Microgateway applies exceptions.

  • Choose a lower security level for the corresponding deny rule group.
    The example configures security level "strict" for all deny rule groups. For the deny rule group SQLI_PARAM_VALUE the security level will be set to "standard".
  •     mappings:
          - name: example
              value: /
              - level: strict
              - rule_group_keys:
                  - SQLI_PARAM_VALUE
                level: standard