HTTP/2 is backward compatible with HTTP/1.x, so it is possible to configure the architecture to implement a front-end server for HTTP/2 while communicating with one or more back-end servers that support only HTTP/1.x. Thus, the front end effectively has to translate or downgrade the requests it receives into the less secure protocol. HTTP downgrading negates the benefits of HTTP/2. If HTTP downgrading cannot be avoided, validate the rewritten/downgraded request against the HTTP/1.1 specification. For example, reject requests that contain newlines in the headers, colons in header names, and spaces in the request method.
If HTTP downgrading is operationally necessary, and the rewritten request is validated against HTTP/1.x specification (i.e., verify requests that contain new lines in the headers, colons in header names, and spaces in the request method are rejected), mark as a CAT III finding. Verify that HTTP/1.x downgrading is disabled. If the HTTP/1.x downgrading is enabled, this is a finding.
Configure the web server to disable HTTP/1.x downgrading. If HTTP downgrading is operationally necessary, validate the rewritten request against the HTTP/1.1 specification, i.e., reject requests that contain new lines in the headers, colons in header names, and spaces in the request method.