Modern browsers can guess a response’s content type even if it lacks the actual
Content-Type header. Moreover, even if the
Content-Type header is in place, browsers will not necessarily defer to the header’s value. This guesswork is made possible by an inherent function residing in most browsers called MIME-sniffing. Albeit introduced to facilitate functionality in cases where header definition was lacking, MIME-sniffing, which is enabled by default, can facilitate Cross-Site Scripting (XSS) exposures under certain conditions.
Suppose that a web application allows its users to upload image files that, in turn, are served via some endpoint. If they are served without any
A lack of
Content-Type headers, or at least the misconfiguration of such, can lead to XSS attacks as written above. Thus, the scale of impact depends on the capability and sensitivity of the web application getting hosed by the XSS attack that was enabled due to
Content-Type the misconfiguration… that is to say anywhere from trivial to disastrous.
To prevent MIME-Sniffing mishaps from occurring due to ineffective or missing
Content-Type headers, developers must:
Provide a valid
Content-Type header according to the file being served Set the
X-Content-Type-Options header to
nosniff so that the browser never attempts to guess the content type.
Verify that every HTTP response contains a Content-Type header.
application/xml content types should also specify a safe character set (e.g., UTF-8, ISO-8859-1).
- OWASP ASVS: 14.4.1