Some unnecessary headers

[domenic]

Based on https://sonarwhal.com/scanner/82d0ae4e-aa8d-4b9b-9d32-24c1b0817136

• We are sending X-XSS-Protection on CSS and SVG resources, but apparently it's only relevant for HTML resources
• We are sending X-Content-Type-Options for HTML and SVG resources, but apparently it's only relevant for script and style. (Maybe this will change with CORB though?)

[annevk]

Yeah, sending X-Content-Type-Options for all makes sense. (There's also a gap in the specification I found out the other day as apparently some browsers use it for navigation too.)

[annevk]

And surely X-XSS-Protection would be relevant for SVG containing script?

[domenic]

I dunno, I guess there's no spec for them, so it's unclear if browsers would process them on SVGs.

[alrra]

sending X-Content-Type-Options for all makes sense.

@annevk sonarwhal used to do that, but then things were changed to only recommend it for scripts and stylesheets because of the reasons specified in the docs, namely:

Note: Modern browsers only respect the header for scripts and stylesheets, and sending the header for other resources such as images may create problems in older browsers.

---

Maybe this will change with CORB though?

Yes.

---

(There's also a gap in the specification I found out the other day as apparently some browsers use it for navigation too.)

@annevk Can you provide more information (or a link)? Thanks!

---

@annevk, @domenic I'm one of the maintainers of the sonarwhal project, so if you have any other feedback, let me know! I'll happily change what sonarwhal suggests if something is not accurate.

[annevk]

@alrra

HTTP/1.1 200 OK
Content-Type: garbage
X-Content-Type-Options: nosniff

<?xml version="1.0"?><test/>

Test that with and without the header and notice the difference. (Note that this behavior is not standardized.)

[annevk]

(Also, sending it for other resources does not create problems. What creates problems is if you send it for resources that are not correctly labeled.)

[alrra]

What creates problems is if you send it for resources that are not correctly labeled.

@annevk Yes, that's was the intend, but I can see the confusion. I've updated to docs to make them more clear, thanks!

Test that with and without the header and notice the difference.

Thanks!

[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.

Also is not this issue basically a dupe of webhintio/hint#1221 now? Or what is still to be discussed here? (Is not it fixed by webhintio/hint@5c798f5 or what was actually the purpose of this issue?)

[annevk]

@rugk whatwg/misc-server is for issues with WHATWG's server setup. I doubt webhintio/hint has access to our keys to make the relevant changes.

[rugk]

Ugh… yeah…

So you still serve the header for all assets?
And here is the reasoning as I see it: webhintio/hint@5c798f5

So is there still something to do in this issue?
Or do you want to wait whether browsers change their decisions about what mime types?

---

Actually I only came here because it is linked on MDN.

nosniff only applies to "script" and "style" types (this restriction may change in the future).

Though I do not see how that link would be fitting here. After all, you are not discussion or indicating browsers may change their decision here or what?
Now I am totally confused… 😕

[annevk]

This issue is not exclusively about nosniff.

[rugk]

So the link on MDN makes no sense…

[annevk]

I guess we can close this now.