This vulnerability is a bit more technical than most — but the consequences are real, and the fix is a single line of configuration. Here is what MIME sniffing is, why it matters, and how to stop it.

What Is MIME Sniffing?

When a browser loads a file, it needs to know what type of file it is — an image, a stylesheet, a JavaScript file, a web page. The server is supposed to provide this information via a Content-Type header. For example, Content-Type: image/jpeg tells the browser it is looking at a JPEG image.

But some browsers — historically Internet Explorer, and to a lesser extent others — do not always trust the Content-Type header. Instead, they look at the actual content of the file and try to guess what it is. This guessing behaviour is called MIME sniffing.

Browsers started doing this to compensate for poorly configured servers in the early web. But the behaviour introduces a serious security vulnerability for any site that accepts file uploads.

How MIME Sniffing Becomes an Attack

Consider a website that allows users to upload files — a profile picture, a document submission, a support ticket attachment. Common enough on business websites.

An attacker uploads a file named profile.jpg, sent with Content-Type: image/jpeg. The server accepts it as an image. But inside the file, mixed into the binary data, is HTML and JavaScript code.

A browser that MIME-sniffs this file might look at those embedded script tags and decide it looks like HTML — and render it as a web page, executing the embedded JavaScript in the context of your website’s domain.

This is effectively a Cross-Site Scripting (XSS) attack delivered through a file upload. The attacker can use that JavaScript to:

  • Steal session cookies and hijack logged-in user accounts
  • Redirect visitors to phishing pages
  • Keylog everything typed on your website
  • Perform actions on behalf of logged-in users without their knowledge

Who Is at Risk?

Any website that allows file uploads and serves uploaded content from the same domain as the main site is potentially vulnerable. This covers a wide range of businesses:

  • Membership sites and client portals
  • HR platforms and recruitment sites
  • Support ticket systems
  • E-commerce sites with product image uploads
  • WordPress installations with media upload functionality

The OWASP Top 10 — the authoritative list of critical web application security risks — has consistently included XSS and content injection vulnerabilities, of which MIME sniffing is a contributing factor.

The Fix: One Header, Zero Effort

The primary fix is adding a single HTTP header to your website’s responses:

X-Content-Type-Options: nosniff

This header tells the browser: trust the Content-Type header I sent — do not try to guess the file type yourself.

When this header is present, browsers will not execute a file labelled as image/jpeg as HTML, even if it contains HTML-like content. Stylesheets and scripts will only load if they are served with the correct Content-Type.

How to add it:

In Apache:

Header always set X-Content-Type-Options "nosniff"

In Nginx:

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

In WordPress, security plugins like Wordfence or Solid Security can add this header through their settings panels.

Additional Protections for File Uploads

X-Content-Type-Options: nosniff is the minimum fix, but if your site accepts file uploads, additional precautions are worthwhile:

  • Serve uploaded files from a separate subdomain (e.g., uploads.yourcompany.co.uk). Even if a file executes, it runs in a separate security context and cannot steal cookies from your main site.
  • Validate file types server-side — not just by extension or MIME type, but by checking the actual file contents (magic bytes).
  • Re-encode images using a server-side image library that processes the pixel data, destroying any embedded code in the conversion.
  • Set a Content Security Policy that restricts what scripts and resources your pages can load.

What to Do Next

  • Check whether your site sends X-Content-Type-Options: nosniff. Use your browser’s developer tools or a free header checker.
  • Add the header to your web server configuration, CDN, or security plugin settings.
  • Review how uploaded files are handled. Confirm that uploads are validated server-side and served appropriately.
  • Test after adding — this header has no visible impact on your site’s functionality and should not break anything.

X-Content-Type-Options: nosniff takes seconds to add, costs nothing, and closes a real attack vector. There is no good reason not to have it.

W3IT’s free security check checks for the X-Content-Type-Options header and other important HTTP security headers. Run it now to see which protections your site has — and which are missing.