Browsers may guess the type of your responses

MediumConfirmedQuick winweb.security-headers.xcto-missing

What this check looks for

Without this header a browser may ignore what you say a file is and decide for itself — which can turn an uploaded image into a running script.

Why it matters

A file uploaded as an image but containing HTML can be served back and executed as a page on your own domain. One header removes the entire class of problem.

When the check passes, your report says: “Browsers are told to trust the content type you declare”.

What it costs your score

When this check fails it removes 8 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.

It shares the web-security.headers family ceiling of 20 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: confirmed
Status when triggered: fail
Deduction: 8 points
Family cap: web-security.headers · 20
Category: Web security
Module: Web security headers
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Send X-Content-Type-Options: nosniff on every response.

It stops a browser executing a file as something other than what you served it as.

Set it globally rather than per route.
Confirm your Content-Type headers are correct first — nosniff makes the browser trust them absolutely.
Make sure the header appears exactly once; a duplicate collapses into a list that browsers ignore.

How to confirm it worked

curl -sSI https://‹host›/ | grep -i x-content-type-options — expect exactly 'nosniff'

The configuration to publish

X-Content-Type-Options: nosniff

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

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

Apache

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

Caddy

header {
	X-Content-Type-Options "nosniff"
}

Cloudflare

Rules → Overview → Create rule → Response Header Transform Rule → Set static → X-Content-Type-Options = nosniff
(Dashboard path as at 2026-09; Cloudflare reorganised these pages and may again.)

The always flag matters: without it nginx omits the header on error responses, which are exactly the ones an attacker aims for. Note also that any add_header in a location block discards every add_header inherited from the server block.
Shown because the response identified Apache. Put it in the virtual host rather than .htaccess: .htaccess is re-read on every request, and Header always set there runs too late for responses the server generates itself.
A Transform Rule adds the header at Cloudflare's edge, so it applies only to responses that reach visitors through Cloudflare. An origin that is reachable directly — by IP, or through a DNS record that is not proxied — still serves the response measured here without it. Setting it at the origin covers both paths.

Technical detail

‹detail›

The only value browsers act on is the single token nosniff, case-insensitive. Anything else — including nosniff inside a comma-separated list, which is what a duplicated header collapses into — is discarded, so this rule is graded on the exact value rather than on the header being present. Setting it also switches on cross-origin read blocking, which is worth having on its own.