Missing X-Content-Type-Options Header (MIME Sniffing)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Security Misconfiguration / Missing Security Header
Typical Severity Low
OWASP A05:2021 – Security Misconfiguration
CWE CWE-693: Protection Mechanism Failure
Also known as MIME type sniffing, Content-type sniffing, nosniff header missing
Affected systems Any web server or application serving HTTP responses without the X-Content-Type-Options header
Relevant standard Fetch Living Standard (WHATWG), RFC 9110

Overview

The X-Content-Type-Options HTTP response header instructs browsers not to perform MIME type sniffing — the practice of inspecting response content to infer its type rather than trusting the declared Content-Type header. When this header is absent or not set to nosniff, certain browsers may override the server-declared content type and interpret the response as a different, potentially executable type. This header is defined as part of the WHATWG Fetch Living Standard and is supported by all major modern browsers.

Sensagraph automatically detects the absence of this header across all scanned HTTP responses.

How it works

MIME sniffing is a browser heuristic introduced to handle misconfigured servers that serve content with incorrect or missing Content-Type headers. Instead of strictly trusting the declared type, the browser reads the first bytes of the response body (the "magic bytes") and attempts to determine the true content type. While this improves compatibility, it creates a security risk:

  • Script execution from non-script resources: If an attacker can upload a file containing JavaScript (e.g., an image or CSV) and the server serves it with a non-script MIME type, some browsers may still execute it as a script if referenced in a <script> tag without nosniff protection.
  • Cross-site scripting (XSS) facilitation: In older browser versions without nosniff, a JSON or text resource containing HTML/JS could be rendered as HTML, enabling XSS attacks.
  • Stylesheet injection: Similarly, resources served as plain text could be interpreted as CSS, enabling CSS-based data exfiltration or UI redressing.
  • Attack preconditions: Exploitation typically requires user-controlled content (file upload, injection point) to reach a page that includes the content in an exploitable context, or a CORS misconfiguration that permits cross-origin reads.

When the X-Content-Type-Options: nosniff header is present, browsers that support it (Chrome, Firefox, Edge, Safari 16+) will block requests where the MIME type does not match the expected type for the resource context (e.g., blocking a response with text/plain from being loaded as a script).

Business impact

In isolation, the missing header represents a low-severity finding. However, it can contribute to higher-severity attack chains in the following ways:

  • Cross-site scripting (XSS): Content sniffing can be chained with user-controlled uploads or injection points to execute arbitrary JavaScript in a victim's browser, leading to session hijacking, credential theft, or unauthorized actions.
  • Data exfiltration: CSS injection via sniffed stylesheets can be used to exfiltrate sensitive page content character by character.
  • Compliance risk: PCI DSS, HIPAA, and ISO 27001 security reviews commonly flag missing security headers. Absence of nosniff may be cited in audit findings.
  • Reputation and trust: Security scanners and browser developer tools visibly flag this deficiency, which can erode confidence among security-conscious users and partners.

How to fix it

  1. Add the header globally: Configure your web server, CDN, or application framework to include X-Content-Type-Options: nosniff in all HTTP responses. This is the only valid value defined by the specification.
  2. Apache: Add Header always set X-Content-Type-Options "nosniff" to your httpd.conf or .htaccess file (requires mod_headers).
  3. Nginx: Add add_header X-Content-Type-Options "nosniff" always; to your server or location block.
  4. IIS: Add a custom HTTP response header named X-Content-Type-Options with value nosniff via IIS Manager or web.config.
  5. Application frameworks: In Express.js, use the helmet middleware (helmet.noSniff()). In Django, set SECURE_CONTENT_TYPE_NOSNIFF = True. In ASP.NET Core, use app.UseXContentTypeOptions() from the NWebSec package or configure it in the response pipeline.
  6. Serve correct MIME types: Independently of the header, ensure all resources are served with accurate Content-Type values. This reduces the browser's motivation to sniff and improves general correctness.
  7. Verify deployment: After applying the fix, inspect HTTP response headers using browser developer tools or a tool like curl -I https://yourdomain.com and confirm the header is present on all relevant responses, including error pages and API endpoints.

References

Frequently asked questions

X-Content-Type-Options is an HTTP response header with a single valid value: nosniff. When set, it instructs supporting browsers to strictly respect the declared Content-Type header and not attempt to infer the MIME type from the response body content. This prevents browsers from treating, for example, a text/plain response as executable JavaScript.

In isolation, this is typically a low-severity finding. However, it can contribute to higher-severity attack chains when combined with user-controlled content uploads or injection vulnerabilities, potentially enabling cross-site scripting (XSS) or CSS-based data exfiltration.

Yes. The nosniff directive should be applied to all HTTP responses, including API endpoints that return JSON, XML, or binary data. Without it, an attacker who can influence the response body might exploit sniffing in contexts where the response is loaded by a browser.

All major modern browsers support this header, including Chrome, Firefox, Edge, and Safari (from version 16 onward). Internet Explorer 8+ also supported the header, making it one of the earliest adopted security headers.

Yes. The WHATWG Fetch specification defines nosniff as the only valid value for this header. Any other value is ignored by browsers and the header effectively has no protective effect.

It can cause issues if your server is already serving resources with incorrect MIME types that browsers were previously correcting through sniffing. For example, if a JavaScript file is incorrectly served as text/plain, setting nosniff will cause browsers to refuse to execute it. The correct fix is to also ensure all resources are served with accurate Content-Type values.