Limit X-Content-Type-Options usage to scripts and stylesheets

[alrra]

Ref whatwg/fetch#395

[molant]

If I understand correctly the issue you point, nosniff is only for scripts and styles. So you are proposing to update the x-content-type-options rule to only validate nosniff in those cases?

[alrra]

So you are proposing to update the x-content-type-options rule to only validate nosniff in those cases?

Yes something like that. Will need to look into things to better understand what needs to be updated.

[Nikerabbit]

It seems there is a misunderstanding here, I'm just not sure whether it is mine or yours.

Per my understanding the issue is the opposite. If you are serving a script file with content type text/javascript then adding X-Content-Type-Options: nosniff does nothing, because you already let the browser know that it can execute it as a script (it would only be relevant if one tried to load a script as a stylesheet or vice versa).

So, again per my understanding, this header must be present on files that are not scripts or stylesheets. Like https://sonarwhal.com/docs/user-guide/rules/x-content-type-options/ says, the goal is to prevent a user uploading (as an example) a PNG file that contains JavaScript and then instructing other users' browsers to load that file as a script file and execute it (even though it is served as image/png).

[alrra]

. If you are serving a script file with content type text/javascript then adding X-Content-Type-Options: nosniff does nothing

Yes, we can make the rule smarter in that sense and not require the header if <script src=..> file is sent with a JavaScript media type and/or <link rel="stylesheet"..> file is sent with text/css. However, my concern is that people that don't integrate sonarwhal as part of their testing will just test once see that everything is fine, and maybe at a later moment get bitten by this.

this header must be present on files that are not scripts or stylesheets.

Yes, we need to update a bit the documentation and provide better server configs. However regarding the server configs I don't think there is a way to target only files that are specified inside <scripts> or <link rel="stylesheet"> so maybe go back and suggest sending the header for everything?

[molant]

We might have to look into CORB

[alrra]

We might have to look into CORB

https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

[Malvoz]

In conjunction to nosniffing CSS and JS (per "Should response to request be blocked due to nosniff?"), the section "Determining whether a response is CORB-protected" in the Google CORB explainer says:

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

Should probably track the progress of adding more CORB-protected MIME-Types in whatwg/fetch#860 (comment) and whatwg/fetch#721 (in any case where the concluded MIME-Type to protect would also require the X-Content-Type-Options header).