Lack of Content Type Headers
Description
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 Content-Type header, then an attacker might be able to upload an HTML document containing malicious JavaScript code in place of the legitimate image. Once done, the next step would be to obtain the direct URL that serves the malicious HTML page which would, in turn, be delivered to the next unwitting victim that ended up navigating to it.
Impact
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.
Prevention
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.
Testing
Verify that every HTTP response contains a Content-Type header. text/*, /+xml and application/xml content types should also specify a safe character set (e.g., UTF-8, ISO-8859-1).
- OWASP ASVS: 14.4.1