audit proposal: http header best practices

[connorjclark]

https://www.youtube.com/watch?v=TNlcoYLIGFk

Some audits for HTTP responses I came up with after watching the above video:

X-Frame-Options

Suggest Content-Security-Policy: frame-ancestors 'self' instead. Offers more consistent behavior across browsers.

Via

Suggest removing or placing behind a X-Debug request header.

Content-Security-Policy

Suggest that it exist. Confirm it doesn't have unsafe-inline, unsafe-eval, or glob-starred CDNs/hosts (*.amazonaws.com).

Referrer-Policy

I suppose there's a valid use case for all values of this header. But what about ensuring that it exists (and suggest it be set to origin-when-cross-origin)?

103 Early Hint

If there are Preload headers, the server should also be sending 103 to make full use of preload.

Feature-Policy

Suggest that it exist. Link to cool resources about it.

Strict-Transport-Security

Suggest it exist.

P3P

Kill.

---

see also https://www.fastly.com/blog/headers-we-want and https://www.fastly.com/blog/headers-we-dont-want

[Malvoz]

• Content-Security-Policy Suggest that it exist. Confirm it doesn't have unsafe-inline, unsafe-eval, or glob-starred CDNs/hosts (*.amazonaws.com).

https://csp-evaluator.withgoogle.com/ also recommends object-src: 'none' if possible (should be covered in https://github.com/GoogleChrome/lighthouse/issues/7159).

Should this audit also discourage:

• Technology-related headers that provide no real value such as Server and X-Powered-By? As not to reveal server information, helps prevent header-bloat as well.

• Use of deprecated headers such as X-Webkit-CSP, X-Content-Security-Policy.

• The Pragma header field in responses. It is a request header, not a response header - but many use it as such.

• Microsoft's Cache-Control extension directives: pre-check and post-check.

• If Cache-Control includes the no-transform directive then ask the author to consider the potential negative impact on users over constrained networks/slow devices. Refer to documentation at https://support.google.com/webmasters/answer/6211428?hl=en

• Public-Key-Pins (+ Public-Key-Pins-Report-Only), due to lack of browser support, perhaps suggest Expect-CT instead?

• Non-standard headers that are nothing but big question marks, e.g. X-Permitted-Cross-Domain-Policies (used to indicate the presence of a "cross-domain policy file" to bypass the same-origin policy, most notably used by Adobe's PDF reader), X-Download-Options (security related header, supported in IE, with support suggestion for Edge - most likely not due to the security-related aspect of it).

Also, for any HTTP header that is recommended to be avoided, the same header should also be avoided in the Vary header field's value.

[optimalisatie]

I would suggest to add a Security score to highlight the importance of security optimization, and it's relation to website quality and SEO.

https://securityheaders.com/ by specialist https://scotthelme.co.uk/ is a good place to start for inspiration.

[Malvoz]

@optimalisatie I believe your suggestion is off-topic from HTTP headers (while I understand you want this potential audit included in a new security category), and so should be a separate issue.

@connorjclark

Referrer-Policy I suppose there's a valid use case for all values of this header. But what about ensuring that it exists (and suggest it be set to origin-when-cross-origin

Going into details here; the default value for Referrer-Policy will most likely change to strict-origin-when-cross-origin, the recommended value should be based on that new default.

Also, might want to include Clear-Site-Data in the list (e.g. give off a warning if Clear-Site-Data: "cache" is in use, as it could be detrimental to user's bandwidth).

[paulirish]

fwiw the reference issue for a Security category is here: https://github.com/GoogleChrome/lighthouse/issues/277