Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: automatically add X-Content-Type-Options: nosniff #24513
Some old browsers have an unfortunate mis-feature where they will detect and interpret HTML in responses that have different
The proposal is to automatically include the
It doesn't solve all issues, for example plugins are still a problem, and even older browsers don't support it, but it's almost free and mitigates the issue in IE8, the most used affected browser (according to https://caniuse.com/usage-table, https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-v-comprehensive-protection/).
There should probably be a way to disable it for users that care about the header overhead and are unconcerned by content sniffing. Maybe setting it to an empty string? Is there precedent?
See also #13150
Not everybody is using web browsers with net/http, and even with just web browsers I’m seeing on Wikipedia that X-Content-Type-Options maybe only applies to Internet Explorer and Chrome.
Including secure application patterns makes sense to me (there’s a lot to learn in the http+browser history), but I think they should be optional to provide for other applications where maximized performance and elegant code is wanted. Toggling a string write to nil in every request is unfortunate at least for elegance.
@andybons I’d add net/http/browser or x/net/http/browser package.
Or I'd point people to a community solution like https://github.com/unrolled/secure
Although maybe this kind of function could just be in net/http. "func SecureBrowserResponse(..."
@pciet We aim to provide security by default (users that don't know to add
User Agent sniffing might be useful here, it is usually unwieldy to maintain, but here we are only concerned about some specific old browsers, those won't change.
I'm +1 on mirroring how Date works.
changed the title
proposal: net/http: automatically add X-Content-Type-Options: nosniff
Apr 2, 2018
referenced this issue
Apr 10, 2018
So we would only target "MSIE 8".
However, I'm now realizing that it will be little use if an attacker can load a resource with a third-party script tag and execute in the context of the target, which would be an issue also with other browsers and with other Content-Types.
But I'm out of my depth in terms of historical web platform security. Maybe @ericlaw1979 can help us here?
Generally speaking, content sniffing is a problem in ALL browsers, not just legacy IE.
Beyond IE9's changes in CSS handling and broadening respect for
While sniffing unrecognized/ambiguous types to HTML has been tightened across browsers over the years, relatively little has been done for other problems with types (particularly scenarios the target can be interpreted as Script or CSS).
There are active vulnerabilities across browsers that enable violation of the same-origin policy and reveal the content of resources that fail to declare
Sending correct MIME types and preventing sniffing to other types is arguably as important as ever in a world of Spectre/Meltdown. See https://textslashplain.com/2018/01/08/content-types-matter-more-than-you-think/ and in particular https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md
@ericlaw1979 Ouch, that's way more widespread than I thought.
We can't help with setting appropriate Content-Types, but we can help setting
How about setting
Let me just restate the reason we in ISE consider this an important long term goal.
So real systems serve hosted content on sensitive origins with a different mime-type than that with which it was received.
This is not limited to the browser. Any system that grants privilege to files with a particular combination of (origin & mime-type) is potentially vulnerable.
@mikesamuel thanks for weighting in.
How do you feel about the conflict between setting nosniff automatically, and using nosniff as a signal to turn off server-side sniffing? (For context, the Go standard library performs Content-Type sniffing on the first 512 bytes of the response when Content-Type is unset. See #24795.)
My concern with server-side sniffing is that it's less context-aware than browser sniffing, and less likely to evolve with the browsers.
@FiloSottile I submitted the original patch to use nosniff as a signal to turn off server-side sniffing. I think it's a good idea since I think it's typically an error when an HTTP response both lacks a Content-type and has a single non-empty body.
Ideally, all header sets for a non-empty body would specify nosniff, but I think we could try to do this on an opt-in basis. I floated Secure Header Sets a while back to try to fill that niche:
A main use case for Content-type sniffing is serving hosted content which is also where polyglot attacks are a major risk.
Having more context can be a good thing but not necessarily when that context is attacker controlled. It's precisely the dependence on context to resolve ambiguity that lets gifjs masquerade as a .js file when used in