X-Content-Type-Options: nosniff Explained
X-Content-Type-Options: nosniff stops browsers from MIME-sniffing responses into executable types. Learn why the header matters and how to verify it.
X-Content-Type-Options is a response header with a single widely used value: nosniff. It tells browsers not to guess a different content type than the one you declared. That blocks a classic trick where an attacker uploads a file that looks like an image or text but is executed as a script.
The header is tiny, easy to deploy, and appears in every serious baseline. Confirm it with a security headers check after you enable it.
The only value you need
X-Content-Type-Options: nosniff
Send it on HTML documents and on downloadable or user-influenced responses alike. Some stacks apply it globally at the reverse proxy so individual apps cannot forget it.
What MIME sniffing risk looks like
- A user-controlled file is served from your origin with a loose or wrong
Content-Type. - A browser sniffs the bytes and treats them as HTML or JavaScript.
- Script runs in your origin context, enabling XSS-style impact.
Always set accurate Content-Type values. nosniff stops guesswork; it does not fix a server that intentionally serves the wrong type.
Relationship to CSP
Content-Security-Policy remains the main defence against injected scripts. nosniff is a cheap second line that closes MIME confusion gaps CSP may not cover alone. See the CSP setup guide when you are ready for deeper script control.
How to verify
- 1Inspect response headers on the homepage and on a static asset path.
- 2Confirm
X-Content-Type-Options: nosniffsurvives CDN caching. - 3Include the check in an automated scan so regressions fail loudly.
If you only ship one header today, HSTS or CSP may outrank nosniff for impact. If you ship a baseline set, nosniff should always be in it. Add the line, redeploy, and move on to the rest of your HTTP security headers.
