Reducing false-positive blocks

Sometimes, requests are blocked by deny rules due to content resembling attacks but may be valid for a web application. These blocks are called false positives. You have several configuration options in the CR DenyRules if you have verified that the target web application is working correctly and a blocked request is a false positive.
This article describes how and where to start reducing false positives.

Narrowing down and reducing false positives

This instruction is a best practice for narrowing down and reducing false positives that can be followed in most cases.

While integrating an Airlock Microgateway with an existing application, you can use the threatHandlingMode: LogOnly to analyze the impact of deny rules on an application running in production. This allows for identifying false positives and configuring exceptions without disturbing productive traffic.

  1. Analyze the logs to narrow down the block_reason, rule_key etc. of the false positives blocks. See Default access log field reference for more information.
  2. Consider choosing a lower security level for the corresponding deny rule group on the affected mapping (e.g., go back from level strict to standard).
  3. Add deny rule exceptions. Deny rules allow the definition of fine-grained exceptions for all attributes. See CR DenyRules for details, including exceptions for JSON content.
  4. If the block pertains to a specific deny rule, the rule can be set to LogOnly‚Äč or Unfiltered to turn off blocking. Note that this should not be done lightly. Instead, you should consider changing the web application if possible.
  5. Check the access logs to verify the deny rule exception works as expected.

Tips for setting up deny rule exceptions

In general, be as specific as possible when defining exceptions. For instance, adding an exception for content type application/pdf may allow bypassing a deny rule simply by adding a header to requests. Whether or not the content is interpreted as a PDF file depends on the application and cannot be controlled by Airlock Microgateway.

  1. Possible deny rule configuration options:
  2. Define a deny rule exception only with blockedData. This way, the configured exception is applied unconditionally to all paths, HTTP methods, remote IP addresses, ...
  3. Define a deny rule exception with blockedData and requestConditions. This is the recommended configuration, as it only applies the exceptions to requests that matches the requestConditions.
  4. Define a deny rule exception only with requestConditions. This configuration should be chosen carefully, as deny rule checks are not applied at all to requests which matches the requestConditions.