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
| Field | What it does |
|---|---|
| Valid Mode | When enabled, edge servers reject requests made with non-RFC-compliant headers that contain invalid characters in the header name or value. Clients receive a 400 Bad Request response. When disabled, edge servers allow such requests, passing the invalid headers to the origin server. In both cases, edge servers write a warning in Akamai's logs. |
| Strict Mode | When enabled, edge servers reject 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. Clients receive a 400 Bad Request response. When disabled, edge servers allow such requests, but correct the violation by removing or rewriting the header line before passing the headers to the origin server. In both cases, edge servers write a warning in Akamai's logs. |
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.
Technical details
The Valid Mode processing rejects any requests if either of these header problems are detected:
- A header name includes any characters outside of this list:
abcdefghijklmnopqrstuvwxyzABCEDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'\*+-.^\_\`|~
- A header value includes any characters outside of this list:
abcdefghijklmnopqrstuvwxyzABCEDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'\*+-.^\_\`|~"(),/:;\<=>?@\[\]{}
Although now obsolete and not recommended by RFC 9110, Akamai allows non-US ASCII characters in the range %x80-FF.
Default platform behavior
Up until the middle of 2023, the Akamai platform has both modes disabled by default.
In the second 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 date, 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:
- 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 edge servers.
- 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.
Updated over 1 year ago