I am doing some penetration testing on my localhost with OWASP ZAP, and it keeps reporting this message:
The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'
This check is specific to Internet Explorer 8 and Google Chrome. Ensure each page sets a Content-Type header and the X-CONTENT-TYPE-OPTIONS if the Content-Type header is unknown
I have no idea what this means, and I couldn't find anything online. I have tried adding:
<meta content="text/html; charset=UTF-8; X-Content-Type-Options=nosniff" http-equiv="Content-Type" />
but the I still get the alert.
What is the correct way of setting the parameter?
This question is tagged with
~ Asked on 2013-08-20 14:27:49
It prevents the browser from doing MIME-type sniffing. Most browsers are now respecting this header, including Chrome/Chromium, Edge, IE >= 8.0, Firefox >= 50 and Opera >= 13. See :
Sending the new X-Content-Type-Options response header with the value nosniff will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.
Oh and, that's an HTTP header, not a HTML meta tag option.
~ Answered on 2013-08-20 14:33:18
Setting a server's
X-Content-Type-Options HTTP response header to
nosniff instructs browsers to disable content or MIME sniffing which is used to override response
Content-Type headers to guess and process the data using an implicit content type. While this can be convenient in some scenarios, it can also lead to some attacks listed below. Configuring your server to return the
X-Content-Type-Options HTTP response header set to
nosniff will instruct browsers that support MIME sniffing to use the server-provided
Content-Type and not interpret the content as a different content type.
X-Content-Type-Options HTTP response header is supported in Chrome, Firefox and Edge as well as other browsers. The latest browser support is available on the Mozilla Developer Network (MDN) Browser Compatibility Table for X-Content-Type-Options:
MIME Confusion Attack enables attacks via user generated content sites by allowing users uploading malicious code that is then executed by browsers which will interpret the files using alternate content types, e.g. implicit
text/plain. This can result in a "drive-by download" attack which is a common attack vector for phishing. Sites that host user generated content should use this header to protect their users. This is mentioned by VeraCode and OWASP which says the following:
This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.
Unauthorized Hotlinking can also be enabled by
Some pesky non-human users (namely computers) have taken to "hotlinking" assets via the raw view feature -- using the raw URL as the
<img>tag. The problem is that these are not static assets. The raw file view, like any other view in a Rails app, must be rendered before being returned to the user. This quickly adds up to a big toll on performance. In the past we've been forced to block popular content served this way because it put excessive strain on our servers.
~ Answered on 2016-05-13 04:43:43