X-Content-Type-Options is an HTTP response header with a single value — nosniff — that tells browsers to honour the declared Content-Type and not try to infer the content type by inspecting the response body. It closes an entire class of MIME confusion attacks that can turn uploaded files into executable scripts.
Browsers historically attempted to be helpful: if a server declared a response as text/plain but the body looked like HTML or JavaScript, some browsers would execute it anyway. This behaviour — MIME sniffing — was intended to compensate for misconfigured servers, but it created a security hole.
The attack path is straightforward: an attacker uploads a file that contains JavaScript but has an innocuous-looking name and extension. The server stores it and serves it with a benign Content-Type such as image/jpeg. A browser that sniffs the file detects the JavaScript and executes it in the context of the page, achieving cross-site scripting without ever injecting code into a legitimate page resource.
User-generated content hosting — profile images, document uploads, avatar storage — is the most common attack surface. Any endpoint that serves files whose content is controlled by users is potentially affected if MIME sniffing is enabled.
nosniff is the only defined value for this header. It has no configuration options.
X-Content-Type-Options: nosniff
With this header present, the browser treats the declared Content-Type as authoritative. If a response destined for a <script> element does not have a JavaScript MIME type, the browser blocks it. If a response destined for a stylesheet does not have a CSS MIME type, the browser blocks it. The content is not sniffed, not reinterpreted, and not executed under a different type than declared.
With nosniff set, browsers apply stricter MIME-type checking for script and style destinations. A script tag requesting a resource that is served with a non-JavaScript Content-Type will be blocked — even if the body content is valid JavaScript. Similarly, a stylesheet link requesting a resource served without a CSS content type will not be applied. This makes correct Content-Type headers a prerequisite: if your server already serves every file with the correct type, nosniff has no negative effect on normal operation.
The practical downside to adding nosniff is essentially zero — provided your server already sets accurate Content-Type headers. Any modern web framework and most static hosting platforms assign correct MIME types by file extension. Before enabling this header on a legacy system, verify that all served file types have matching Content-Type declarations, particularly for dynamically generated content. An audit of your server's MIME type configuration takes minutes and is good practice regardless of this header.
X-Content-Type-Options and Content-Security-Policy are complementary. CSP controls which origins scripts may be loaded from; nosniff ensures that whatever is loaded is interpreted as the type it claims to be. A thorough defence uses both: CSP to allowlist trusted sources, and nosniff to prevent type confusion within those sources.
Audit nosniff with the headers tool
Open Headers Tool