Content-Type, also known as MIME type, lets you specify the data type of the content.
Strict-Content-Type: true should force the Content-Type to be used strictly. This disables browsers guessing the content type for e.g. images and video, as many of them do.
(For example https://ftb.cursecdn.com/FTB2/static/FTBPresentsCrackpackIcon.png is a JPEG served as an image/png. This would be disallowed with Strict-Content-Type)
Isn’t this what the nosniff content type option does?
nosniff was explicitly designed to not break images.
strict-content-type was explicitly designed to break images.
What use-case is your recommendation aiming to solve?
Developers generally aren’t great about setting the proper mime types. Nor are the applications they use. Browser inference here benefits the end user experience. So what is the use-case that requires a new strict mode to solve?
Strict-Content-Type is to nosniff/Content-Type what XHTML is to HTML.
It’s meant to explicitly shout at the developer, at the expense of the end-user, just like XHTML. It also makes processing easier for automated tools, just like XHTML.
That’s just a comparison of technologies, not an actual use case. A use case is something to the effect of “I am experiencing $X issue which currently can’t be worked around. Having this feature added would alleviate this problem.”
Unless there are clearly visible problems that is being caused by not having strictness, it’s highly unlikely any browser is going to want to put effort into adding it.
The point is that mismatched content type breaks many automated tools.
By being strict about it, you can also break browsers while at it. This is a good thing in many cases because it promotes better compatibility - your content is gonna show up the same whether in a browser or in a minecraft launcher.
Well, as discussed earlier, from the sound of it nosniff in the content header options is what you’re looking for. At least for stylesheets and scripts. However, applying this to images broke web sites. So, that application isn’t going to be applied in the web.
Without a specific use-case though, not much is possible.
The use case is to break the website if you have your type-safety wrong.
It’s strongly typed websites. We use strongly typed languages, why shouldn’t we have strongly typed websites?
I want my website to give a compile error if the types are wrong/mismatched. That is exactly what this is for.
That’s what nosniff is missing. nosniff is just a security feature, this is a… something else.
We did try that in early Web days. NCSA Mosaic had a “bad html” icon that would light up if there were syntax errors (which turned out to be true on almost all pages) and offered to email the Webmaster to let them know, if that metadata was present.
It’s already, strictly speaking, a violation of HTTP to serve up content that doesn’t match its corresponding MIME media type. Adding a new HTTP header isn’t going to change that and isn’t going to change the fact that it hurts the wrong people - the users, who blame the browser, rather than the authors and developers.
You’re better off using a validation service, i’d say.
then make a compromise: strict types for hotlinking, guessing for <img> tags?
this gives a slightly-inconsistent-enough behaviour that users will know it’s the developer’s fault. some users will assume the website is broken while others will just assume the website doesn’t support hotlinking.
It is absolutely not a security feature. It’s a feature so a site can serve static file without risking them being hot-linked as resources to be used in a website. For example, you can’t hotlink github’s raw content from repositories as a style or script src on your website. It has nothing to do with a site’s security. It’s all about a site being able to offer a service without having their service abused by users.
If you are worried about other places using your server’s resources as content for themselves, there are already ways of handling that in your web server config. Checking the origin of the request and denying it if you don’t recognize it. There is absolutely no need for a new strict mode to have anything to do with hotlink prevention.
It’s not as easy as just saying they’ll know, and boom they’ll know. In reality, most users have no idea what’s going on so they blame the closest thing to them, the browser. Because that’s what they understand to some degree.
nosniff is so text files don’t get treated like .exe files or w/e, e.g. because the file upload on your website is a bit risky.
remember when you had to validate everything on the server, because we didn’t have nosniff?
nowadays things are much easier. we still do server-side validation, but it’s not as strictly necessary as it once was.
