Strict Header Parsing

This behavior specifies how the edge servers should handle requests containing improperly formatted or invalid headers that don’t comply with RFC 9110.

Why you need it

Some clients may send invalid or incorrectly-formatted, non-RFC-compliant request headers. If such requests reach the origin server, this vulnerability can be exploited by a “bad actor”, for example to poison your cache and cause invalid content to be returned to your end users.

Use Strict Header Parsing to tell the edge servers what requests to reject, independently of the ​Akamai​ platform's default behavior. Therefore, you may either get the protection earlier than the global customer base or defer changes to a later time, though not recommended.

Features and options

FieldWhat it does
Valid ModeRejects requests made with non-RFC-compliant headers that contain invalid characters in the header name or value. When disabled, the edge servers log a warning and allow such requests, passing the invalid headers to the origin server.
Strict ModeRejects requests made with non-RFC-compliant, improperly formatted headers, where the header line starts with a colon, misses a colon or doesn’t end with CR LF. When disabled, the edge servers log a warning and allow such requests, but correct the violation by removing or rewriting the header line before passing the headers to the origin server.

Note that the two modes are independent – each of them concerns different issues with the request headers. As ​Akamai​ strives to be fully RFC-compliant, you should set both these options to On as best practice.

Default platform behavior

Up until the start of 2023, the ​Akamai​ platform has both modes disabled by default.

In the first quarter of 2023, ​Akamai​ will start rejecting requests that include headers with invalid characters and will enable the Valid Mode by default.

At a later time, ​Akamai​ will start rejecting requests that include headers with no name, colon or proper line end and will enable the Strict Mode by default.

Implementation

Enabling both options ensures that ​Akamai​ edge servers reject requests with invalid headers and don’t forward them to your origin. In such cases, the end user receives a 400 Bad Request HTTP response code.

If you don’t want to block traffic from a known client that sends invalid request headers:

  1. Add the Strict Header Parsing behavior to the Default Rule with all options set to On. This ensures that by default, requests with invalid request headers are rejected by the ​Akamai​nam edge servers.
  2. Add a new rule with matches on the attributes that identify traffic from that client (such as User-Agent, hostname, path etc.). Add the Strict Header Parsing behavior to the same rule with all options set to Off. This way only specific requests will be allowed through to your origin server.

In the long-term, you should update any client which sends invalid headers so that it becomes fully RFC-compliant.This is the only way to protect your origin server from the cache poisoning vulnerability.