X-Content-Type-Options is set
Why it matters
Browsers with MIME sniffing enabled attempt to guess a file's content type by reading its bytes, ignoring the Content-Type header. Attackers exploit this to serve malicious payloads in files uploaded or hosted as innocuous types — a file labeled text/plain containing JavaScript can be executed as a script. This crosses directly into CWE-79 (XSS) territory and OWASP A03 (Injection). The X-Content-Type-Options: nosniff header is a single-line fix that disables this guessing. It costs nothing to send and eliminates an entire class of content-type confusion attacks on every browser that honors it, which is all major browsers.
Severity rationale
Low because MIME sniffing attacks require an attacker-controlled upload or hosting vector, making exploitation dependent on other weaknesses being present first.
Remediation
Add the X-Content-Type-Options: nosniff header to all responses. This is a single directive with no configuration options:
# nginx
add_header X-Content-Type-Options "nosniff" always;
In Next.js next.config.js:
{ key: 'X-Content-Type-Options', value: 'nosniff' }
Most CDNs (Vercel, Cloudflare) also expose this as a toggle in their security settings dashboard. Confirm with curl -sI https://yoursite.com | grep -i x-content-type.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Site Health Check audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-79 — Improper Neutralization of Input During Web Page Generation (XSS)
- owasp:2021 · A03 — Injection
Taxons
History
- 2026-04-18·v1.0.0·Initial import from site-health-check·automated
- 2026-04-20·v1.1.0·Add Phase 6.0 detect-curl snippet for X-Content-Type-Options probe·by cakleinman