The fix, in one snippet
1. chrome://extensions (Firefox: About:addons)
2. Disable anything that rewrites headers or requests
3. Reload this page and run the check again
4. If it still fails, update the browser: Chrome://settings/helpIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
The scan page includes <script src="…/probe/nosniff.js">. The probe answers with valid JavaScript that sets a global flag, but with Content-Type: text/plain and X-Content-Type-Options: nosniff. A compliant browser refuses to execute it; if the flag appears, the check fails. A second probe serves a stylesheet the same way and we test whether its rule was applied with getComputedStyle(). Limits are the same as for X-Frame-Options enforcement: an extension or proxy that strips headers looks identical to a browser that ignores them.
Why it matters
MIME sniffing is the browser guessing a resource's type from its bytes when the declared type looks wrong. Attackers exploit it on sites that accept uploads: a file uploaded as an "image" or a text attachment is really JavaScript, and a page elsewhere includes it as a script, or the file is rendered as HTML and becomes cross-site scripting. nosniff tells the browser to trust the declared type and refuse scripts and stylesheets served with the wrong one. Chromium's cross-origin read blocking also relies on it to keep cross-origin data out of a page's process. If your browser sniffs anyway, every site's nosniff header is ineffective for you.
How to fix it
Update the browser, disable extensions that modify headers, and rerun the scan in a clean profile or private window. If it only fails on one network, the proxy is the likely cause. There is no browser setting to turn sniffing off separately; enforcement is built in. Site owners set the header on every response:
X-Content-Type-Options: nosniffand serve correct Content-Type values for scripts (text/javascript) and styles (text/css). See the website-side nosniff check and HTTP security headers explained.
Where this fits
Browser enforces X-Content-Type-Options is check 4 of 16 that the browser security & privacy check runs under browser privacy and policy enforcement, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits WebRTC IP address leak (high), where webRTC revealed an IP address that differs from the one your connection uses, typically your real address behind a VPN or proxy. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Browser enforces X-Content-Type-Options closes one route in. Immediately below it: Browser enforces X-Frame-Options, where your browser displayed a page inside a frame even though that page was served with X-Frame-Options: DENY, so the clickjacking protection sites rely on is not being enforced; Browser fingerprint uniqueness, where the combination of signals your browser exposes matched no other visitor in our sample, so it could be used to recognise you across sites without cookies; Third-party cookies allowed, where your browser accepts cookies set by third-party domains embedded in other sites, which is the basic mechanism of cross-site tracking.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Browser enforces X-Content-Type-Options (medium severity)
Scanner check id: nosniff-enforcementThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
