Loading...
WebShield Audit
Medium severity
Missing X-Content-Type-Options
Prevents the browser from "guessing" the file type (MIME sniffing) and forces it to trust the server's declared type.
Business risk
If you allow users to upload images, an attacker might upload a file named `image.jpg` that actually contains malicious JavaScript. Without this header, Internet Explorer and older Chrome versions might look at the file content, see script tags, and execute it as JavaScript (XSS). This header says "No, I said it is a JPEG, treat it as a JPEG."
Technical details
The only valid value is `nosniff`. This is a set-and-forget header that should be on every response.
How to detect it
This is a one-line header. Either `nosniff` is present on every response or it is not. Check your origin and any subdomain that serves user-uploaded content.
Read the header
curl -sI https://yourdomain.com | grep -i x-content-type-optionsCheck user-content subdomain
curl -sI https://uploads.yourdomain.com/some-file.jpg | grep -i x-content-type-optionsCommon pitfalls
- Setting `nosniff` while serving assets with wrong `Content-Type`. Once sniffing is off, the browser honors the declared type strictly. A script served as `text/html` will be blocked. Fix your MIME mapping first.
- Forgetting to set it on CDN responses. Your origin may be protected but a separate CDN for uploads or static files often is not. Audit every response path.
- Using any value other than `nosniff`. The only valid value is `nosniff`. Misspelled variants (`no-sniff`, `off`) are ignored.
- Assuming frameworks set it automatically. Some do (Next.js does not by default), some do not. Verify with curl; do not assume.
- Applying it only to HTML responses. JavaScript, CSS, JSON, and image responses are the ones that matter most - they are the surfaces the sniffer misuses.
Remediation guide
External references
Frequently asked questions
Does this header apply to images?
Yes. An attacker-uploaded "image" that actually contains HTML could be sniffed and rendered as HTML in legacy browsers. `nosniff` forces the declared `Content-Type` to be honored across every response type.
Will this break anything?
Only if you are serving content with the wrong `Content-Type` today. That is already a bug; `nosniff` surfaces it. Fix the MIME mappings, then the header is safe to ship globally.
What MIME type should my JSON API use?
`application/json`. `text/plain` or `text/html` for JSON responses will be blocked by modern browsers when `nosniff` is present, and some XSS defenses (like CORB/ORB) depend on correct MIME labeling.
Keep going
Verify your fix
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.