Require X-Content-Type-Options headers for all responses? [3]

[GuillaumeRossolini]

Following your recommendation (through the webapp), we kept the "X-Content-Type-Options" response header only for JavaScript and CSS resources. However, another recommendation of the community (in this case Scott Helme) is to use this same header for all content types, though MDN seems to agree with you rather that Scott.

Example here:
https://securityheaders.com/?q=https%3A%2F%2Fwww.instantluxe.com%2F&followRedirects=on

I'm confused as to how this header should be used.

[alrra]

@GuillaumeRossolini Thanks for opening this issue.

I'm confused as to how this header should be used.

From our docs:

Note: Modern browsers only respect the header for scripts and stylesheets, and sending the header for other resources (such as images) when they are served with the wrong media type may create problems in older browsers.

But, given the recent discussions (#767, whatwg/misc-server#90 (comment)), we should probably revert the change made in 6a2f29b.

[emilbjorklund]

Further feedback on this: found this thread on Mozilla's HTTP Observatory, which in turn links to Google’s docs on how they mitigate side-channel attacks, which then links to docs on Chrome's CORB, which says this:

CORB decides whether a response needs protection (i.e. if a response is a JSON, HTML or XML resource) based on the following:

• If the response contains X-Content-Type-Options: nosniff response header, then the response will be CORB-protected if its Content-Type header is one of the following:
  • HTML MIME type
  • XML MIME type (except image/svg+xml which is CORB-exempt as described above)
  • JSON MIME type
  • text/plain

[...]

[rugk]

Actually also "HTML" can be a malicious mime type, as it can obviously embed JS. (Maybe also other types such as SVG?)

See https://www.youtube.com/watch?v=dBJt3eR8-bg for a talk by @hannob on that subject.