CR DenyRules

Airlock Microgateway has built-in deny rules that effectively block malicious requests to upstream web applications. This deny rule set is constantly evolving and updated to respond to the latest threats.
Each deny rule is identified by a deny rule key that can be referenced for configuration purposes. Each ruleKeys refers to different attack types such as SQL injection, XSS, TEMPLATE injection, etc.

  • The CRD DenyRules allows configuring the following in the CR:
  • The security level of the applied deny rules.
  • The threatHandlingMode (e.g. Block or LogOnly) can be configured globally and on the rule key level.
  • Deny rule overrides to change settings (e.g. security level or threat handling mode) of specific deny rules.
  • Deny rule exceptions for requests that match one or more deny rules but should not be blocked. Exceptions can be configured and fine-tuned to reduce the number of false positives using blockedData and/or requestConditions based on various characteristics.
  • The definition of custom deny rules.

This CR needs to be referenced in the CR ContentSecurity.

Example configuration

For the default and an example configuration including custom rules, see CR Deny Rules reference documentation.

  • The example covers:
  • spec.request.builtIn.settings – global deny rule settings
  • spec.request.builtIn.override – deny rule override, to override the global deny rule settings for some deny rules
  • spec.request.builtIn.exceptions – deny rule exceptions
  • spec.custom.rules – custom deny rule definition

In addition to the API Reference documentation, this article adds useful background information for the available configuration options.

Security levels

Different security levels can be configured on global and deny rule levels. This makes it possible to configure the balanced processing of requests with a high level of security and a low number of false positives simultaneously.

Global level



In level Unfiltered, no deny rules are applied. This means, no requests will be blocked.


Deny rules in level Basic focus on a low false-positive rate, simplifying the integration of applications. Note, however, that certain attack variants may not be covered.

  • Indications for using the level Basic:
  • Level Standard requires too many exceptions.
  • The upstream application access is protected by authentication.


Level Standard is the default setting. It provides strong filters and a low false-positive rate. Exceptions may be required for input fields containing syntactical elements similar to JavaScript or SQL.

  • Indications for using the level Standard:
  • The application is complex or dynamic.
  • The application uses many input fields with unrestricted input values, e.g., free texts or comments.
  • Application access is protected by upstream authentication.
  • Level Strict requires too many exceptions.


Level Strict focuses on blocking many potential attack variants. This level is recommended for very sensitive applications and typically requires some integration effort.

  • Indications for using level Strict:
  • Login and critical pages are exposed directly to the Internet without upstream authentication.
  • The application is rather simple.
  • Application data is very sensitive (high risk).
  • Low code quality of an application.

Override global settings for specific deny rules

For fine-tuning, i.e., to reduce the number of false positives, the security level or the threat handling mode for individual deny rules may be configured differently from the global settings. To do so, configure non-global security levels for deny rules using the ruleKeys or the types element.

For an override example, see CR Deny Rules reference documentation, spec.request.builtInDeny.override.

Deny rule exceptions

Deny rule exceptions can be defined for data elements that have been blocked by a deny rule to reduce false positives using:

  • blockedData exceptions for blocked data elements, e.g., for blocked parameters, headers or JSON data.
    Note that blockedData only allows requests if the string triggering the false positive was in the configured parameter, header or JSON data.
  • Example deny rule exception:

    kind: DenyRules 
      name: deny-rules-example 
            - blockedData: 
                      exact: search 

    The example above creates a deny rule exception for the parameter search

    • With this exception, a request with the search parameter is not blocked if the search parameter triggers the deny rule.
    • With this exception, a request with the search and language parameter is still blocked if the language triggers the deny rule.

    The same mechanism described in the example applies to other blocked data elements such as parameters, headers or JSON data.

    See also article Deny rule exceptions for JSON content.

  • requestConditions exceptions for general characteristics of blocked requests, e.g. request path or originating remote IP.
  • Possible deny rule configuration options
  • Define a deny rule exception only with blockedData:
  • This way, the configured exception is applied unconditionally to all paths, HTTP methods, remote IP addresses, ...

  • 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.

  • 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.

For a deny rule exception example, see CR Deny Rules reference documentation, spec.request.builtInDeny.exceptions.

Custom deny rules

Custom deny rules can be configured as required to complement the built-in deny rules.

  • Difference to built-in deny rules:
  • Custom rules can be added in the CR DenyRules.
  • Security levels and exceptions cannot be applied to custom deny rules.

If one of the configured rules matches a request, the ruleKey is included in the corresponding access log message. Therefore we recommend using short, descriptive denominations for rule keys.

Note that the ruleKey must be a unique denomination and match ^[A-Z][A-Z0-9_]*$, e.g. ruleKey: MY_CUSTOM_KEY_01.

For a custom deny rule example, see CR Deny Rules reference documentation, spec.custom.rules.