HTTP Security Headers

X-Content-Type-Options

One value — nosniff — that stops the browser from guessing a file's type and running, say, an uploaded image as JavaScript.

What it is

Historically browsers would 'sniff' a response's bytes and override the server's declared Content-Type if they thought they knew better. That behavior enabled attacks where a file uploaded as an image, but actually containing script, was executed as JavaScript. X-Content-Type-Options: nosniff disables sniffing so the browser strictly honors the declared type.

Only one valid value

The header takes exactly one token: nosniff. There is no other value.

Example

HTTP RESPONSE HEADER
X-Content-Type-Options: nosniff

With nosniff, a stylesheet is only applied if served as text/css, and a script only runs if served with a JavaScript MIME type — so a mislabeled or malicious upload cannot be coerced into executing.

Why it matters

  • It blocks MIME-confusion attacks where user-controlled content is interpreted as an executable type (script or stylesheet).
  • It hardens sites that host user uploads, where an attacker controls file bytes but not the declared Content-Type.
  • It also enables the browser's Cross-Origin Read Blocking (CORB/ORB) protections, which rely on nosniff being present.

Common mistakes

  • Omitting it on file-download or user-upload endpoints — the exact places sniffing is most dangerous.
  • Serving assets with a wrong or missing Content-Type and then adding nosniff, which correctly refuses to run them and breaks the page. Fix the Content-Type first.
  • Assuming other headers imply it — no other header disables MIME sniffing.

How WebInspect checks this

  • WebInspect checks for X-Content-Type-Options: nosniff and flags its absence as an easy, high-value fix.
  • It verifies the value is exactly nosniff and warns on any other token.
  • It correlates a missing nosniff with responses that also lack a correct Content-Type to highlight sniffing risk.