CR HeaderRewrites

Airlock Microgateway offers built-in header lists and header filtering/rewriting configuration options.

  • The predefined built-in header lists are constantly evolving and updated to respond to the latest threats and new requirements.
  • Custom header rewrite rules can be added to address various integration requirements and to prevent information leakage by response headers and attacks by request headers.

With the configuration options, request and response headers can be added to or removed from upstream and downstream traffic.

The content of this CR is split into two main sections request and response. Both sections can be complemented with custom rules.

This CR needs to be referenced in the CR ContentSecurity.

The following actions can be configured for both built-in and custom rules:

Configured action

Additional information

allow

  • It is possible to disable filtering based on header allow lists using the allHeaders: {} option. In this case, you should use an equivalent set of remove rules to avoid unwanted information leakage through response headers or attacks through request headers.
  • Filtering with header allow lists can be enabled using the matchingHeaders configuration element.

remove

  • The configuration options for rules in the remove section are similar to those in the allow section.

add

  • To add a header with the given name and value. In addition, a mode parameter can be added to define the behavior in case the header already exists.

    • It is set to ​AddIfAbsent​ by default but could be set to OverwriteOrAdd.

Processing order of header actions

  1. Request/response headers are processed in the following order:
  2. Remove all headers, that are not explicitly listed in a built-in or a custom allow rule.
  3. Remove all headers, that are explicitly listed in a built-in or a custom remove rule.
  4. Add all headers, that are listed in a built-in or custom add rule.

Example configuration

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

  • The example covers:
  • spec.request – request header rules
  • spec.response – response header rules
  • custom – multiple custom header rule examples

Logging

Header rewrite actions are not displayed in the access log by default. The CR HeaderRewrites features an Integration operation mode that enriches the access log output with information and details not logged in Production mode. The additional log information are useful for application integration and fault-finding tasks, i.e., to discover potential header-related issues.

Note that the extended logging output of the Integration mode results in larger log messages and requires more storage.

Example log output in Integration mode:

details...
   "airlock": { 
    "header_rewrites": { 
      "response": [ 
        { 
          "headers": [ 
            "content-type" 
          ], 
          "type": "remove-rule", 
          "applied_rules": [ 
            "Remove Content Type Response Header" 
          ], 
          "action": "remove" 
        } 
      ], 
      "request": [ 
        { 
          "type": "allow-rule", 
          "applied_rules": [ 
            "Standard Allowed Request Headers", 
            "Allow custom request headers", 
            "Propagate X-Forwarded-For to upstream" 
          ], 
          "action": "remove", 
          "headers": [ 
            "front-end-https", 
            "x-forwarded-host", 
            "x-forwarded-port", 
            "x-forwarded-proto", 
            "x-forwarded-server", 
            "x-real-ip", 
            "accept-encoding" 
          ] 
        } 
      ] 
    },