Tab – Request Actions

Section – HTTP Headers

To control which HTTP headers are allowed or removed from incoming requests, Airlock Gateway can use an allow list and⁠/⁠or a deny list. Both lists consist of default entries maintained by Airlock and configurable components defined by the user. These mechanisms support both positive (whitelisting) and negative (blacklisting) security models, and they can be used independently or in combination to suit different security strategies. This article explains how the lists work, how they interact with each other and with other actions, and how to customize them effectively.

 
Risk

For security reasons, the pattern ^$ is pre-filled in the Additional allowed headers and Additional denied headers fields. This pattern matches only empty strings, preventing unintended header matches. You can replace it with a specific RegEx pattern as needed.

  • Leaving the field completely empty would match all headers, which may lead to to unintended behavior.
 
Notice

Updating Airlock Gateway may change the default lists because they evolve with new security requirements.

Processing behavior and order

  1. The RegEx patterns defined in the Request Actions tab are evaluated case-insensitively—except in fields that provide a dedicated case-sensitivity toggle (). The lists and actions are processed in the following order:

  2. Allow List – headers not matching any entry are removed
  3. Deny List – headers matching any entry are removed, even if previously allowed
  4. Default Actions – applied to any remaining headers
  5. Custom Actions – applied last
  6.  
    Notice

    This order corresponds to the sequence shown in the GUI. It ensures that a deny list entry can still remove a disallowed header that has matched an allow list entry.

Subsection – Allow List

Setting

Description

Default header allow list

Preconfigured RegEx pattern for allowed headers. Can be enabled (green with check mark) or disabled (gray).

Additional allowed headers

A custom RegEx pattern for additional allowed headers can be added to the input field when enabled (green white check mark).

 
Info

Headers that match the allow list pattern remain in the request. Non-matching headers are removed before the request is forwarded.

Subsection – Deny List

Setting

Description

Default header deny list

Preconfigured RegEx pattern for denied headers. Can be enabled (green with check mark) or disabled (gray).

Additional denied headers

A custom RegEx pattern for additional denied headers can be added to the input field when enabled (green white check mark).

 
Info

Headers that match the deny list pattern are removed from the request. Non-matching headers are not affected and remain in the request.

Choosing and implementing a strategy

Strategy

Pros

Cons

Allow-only

Minimal attack surface: every disallowed header is removed automatically.

Higher risk of false positives: every legitimate header must explicitly be allowed.

Deny-only

Quick to set up and low risk of accidentally blocking a new legitimate header.

Unknown or newly invented illegitimate headers pass through unless they are added to the deny list.

Combined

Fine-grained control: first, the set of legitimate headers is reduced by the allow list, then known illegitimate ones are removed by the deny list.

More complex to configure.

Blocking a header that is part of the Default header allow list

  1. Add the RegEx token of the relevant header to the Additional denied headers field.
  2. The deny list is evaluated after the allow list. Therefore, the deny list overrides the previous allow decision.

Keeping a header that is part of the Default header deny list

  1. Disable the Default header deny list.
  2. Enable the Additional denied headers list.
  3. Copy the RegEx pattern of the Default header deny list field and paste it into the Additional denied headers field.
  4. Remove the token of the undesired header from the pasted pattern.
  5. The headers previously denied will still be removed—except for the header you chose to keep.

Subsection – Default Actions

 
Info

Request and response actions allow flexible administration of HTTP headers. Request and response headers can easily be modified based on patterns in header names or values. Airlock Gateway comes with a set of built-in default actions defined globally. Whether default actions are active or not is controlled globally. However, the activation state of default actions can be overridden on mappings.

Built-in action names have the prefix (default):

  • Expand the action to see the actual configuration, including action type and RegEx pattern.
  • To display a textual description, click on the icon.

Configuration option

Description

disabled (gray)

When disabled, the default action is not processed for this mapping.

enabled (green)

When enabled, the default action is processed for this mapping, even if the default action is disabled globally. For global default actions, see article Submenu – Default Actions.

inherited from default (gray with arrow)

When inherited from default is enabled but gray, the default action is not processed for this mapping, because the global default action1 is disabled.

inherited from default (green with arrow)

When inherited from default is enabled, the default action is processed for this mapping, because the global default action1 is enabled.

1

For global default actions, see article Submenu – Default Actions.

Subsection – Custom Actions

Name of the setting

Description

Name

Actions are identified by a name that must be unique.

Action

The action that takes place on pattern match.

Selectable options:

  • Add header
  • Add missing header
  • Add or replace header
  • Remove header
  • Header redirect
  • Geolocation redirect
  • Rewrite header

Header Name Pattern

RegEx to match the request headers that should be affected by this custom action.

Header Value Pattern

RegEx to match the request values that should be affected by this custom action.

Further information and links

Internal links: