x-content-type-options 1.0.0

X-Content-Type-Options Check v1.0.0

Status

• Version: 1.0.0
• Check identifier: x-content-type-options
• Input contract: [email protected]
• Output contract: [email protected]
• Scope: page

Abstract

This check validates X-Content-Type-Options: nosniff on the scanned browser-loadable response. It verifies header presence, parses the effective nosniff value using Fetch-compatible list behavior, reviews the response Content-Type, and, when Chrome response evidence is available, reviews sampled same-origin responses loaded during page render.

Observed Chrome responses are sampled evidence. The check does not claim complete site-wide coverage for routes Chrome did not request.

Motivation

Browsers historically sniffed response bytes when Content-Type was absent or incorrect. MIME sniffing can turn a low-privilege response, such as text or an upload, into executable HTML or script-like content.

X-Content-Type-Options: nosniff asks browsers to trust the declared media type instead of guessing. It is most useful when paired with accurate Content-Type headers.

Normative Model

The WHATWG Fetch Standard defines the X-Content-Type-Options response header and the nosniff value.

The only defined value is nosniff, matched case-insensitively. Fetch derives the effective value by getting, decoding, and splitting X-Content-Type-Options values. If the first split value is an ASCII case-insensitive match for nosniff, nosniff is active.

Fetch directly applies nosniff request blocking to script-like and style destinations:

• script-like responses are blocked when their MIME type is missing or not JavaScript
• stylesheet responses are blocked when their MIME type is missing or not text/css

RFC 9110 defines Content-Type as the response header that identifies the representation media type. nosniff does not replace correct Content-Type.

Applicability

The check applies to the scanned browser-loadable HTTP(S) response and expects a renderable representation.

Response statuses that do not carry a renderable representation, such as 204 No Content, 205 Reset Content, 304 Not Modified, and redirects, fail this check when scanned as the primary page response.

When Chrome-observed response evidence is present, the check reviews sampled same-origin responses such as documents, scripts, stylesheets, fetch/XHR responses, images/SVG, fonts, text, JSON, and XML. Third-party responses are recorded only as context because the scanned site may not control them.

Pass Criteria

The check passes baseline validation when:

• the scanned response has a renderable body
• X-Content-Type-Options is present
• the first effective value is nosniff
• the header has no extra non-conformant values
• Content-Type is present and parseable
• the observed Content-Type is plausible for the scanned response
• sampled same-origin browser responses, when available, consistently emit conformant nosniff

Warning Criteria

Warnings include:

• the first effective value is nosniff, but extra values are present
• nosniff is present but Content-Type is missing
• nosniff is present but Content-Type is malformed
• the scanned response looks like HTML but is not served as text/html or application/xhtml+xml
• sampled same-origin browser responses omit nosniff
• sampled same-origin browser responses use non-conformant X-Content-Type-Options values
• Chrome response evidence is unavailable, so route consistency cannot be sampled

Failure Criteria

Failures include:

• scanned response does not have a renderable body
• applicable browser-loadable response omits X-Content-Type-Options
• the first effective value is not nosniff
• the value is malformed, such as none, off, nosniff=1, nosniff; mode=block, or another unsupported token

Absence on sampled subresources is warning-level in this version unless the scanned page response itself fails. This keeps the result tied to observed evidence without claiming every route has been crawled.

Evidence Model

The check emits step-level evidence for:

• final URL and status
• response content type
• body/renderability classification
• raw X-Content-Type-Options summary
• parsed split values
• first effective value
• whether nosniff is active
• whether the value is conformant
• extra values
• parsed Content-Type media type
• whether the media type is plausible for the scanned response
• observed Chrome response count
• same-origin observed response count
• eligible sampled response count
• missing or malformed nosniff counts in sampled responses
• summarized affected sampled responses

Evidence must not include cookies, authorization headers, complete response header dumps, complete HTML, request credentials, uploaded file contents, or unrelated sensitive values.

Validation/Scoring Steps

• applicability (0.15): classify response status, body presence, and eligibility.
• header-presence (0.25): check for X-Content-Type-Options on the scanned response.
• value-syntax (0.25): parse split values, first effective value, case-insensitive nosniff, extra values, and malformed values.
• content-type (0.20): validate Content-Type presence, parseability, and plausibility.
• observed-responses (0.15): when Chrome response evidence is available, review sampled same-origin responses for nosniff and Content-Type signals.

Standard Behavior

If an eligible browser-loadable response lacks X-Content-Type-Options, the result fails.

If the header exists but the first effective value is not nosniff, the result fails.

If the first effective value is nosniff but extra values are present, the result warns because browser behavior may still activate while the header is non-conformant.

If nosniff is present but Content-Type is missing or implausible, the result warns.

If Chrome-observed same-origin responses are missing or misusing nosniff, the result warns and identifies sampled affected responses.

Non-Standard And Real-World Behavior

Security header scanners commonly expect X-Content-Type-Options: nosniff across browser-facing responses, even though Fetch's strict request-blocking algorithm directly targets script-like and style destinations.

Many sites emit nosniff globally from a web server, CDN, reverse proxy, or application middleware. That is generally safe when Content-Type is configured correctly. It can reveal misconfigured JavaScript or CSS resources because browsers may block them once nosniff is active.

Some legacy applications depend on MIME sniffing to compensate for incorrect media types. The correct remediation is to fix Content-Type, not to omit nosniff.

Non-Goals And Limitations

This check does not:

• prove every route on the site sends nosniff
• crawl upload, download, API, or authenticated routes unless Chrome requested them during render
• prove every resource has a correct media type
• execute browser-blocking assertions beyond observed response metadata
• replace CSP, HSTS, CORP, COEP, CORS, Referrer-Policy, or download-safety checks
• treat nosniff as protection when the declared Content-Type is wrong
• pass responses that cannot contain or render content when they are scanned as

the primary page response

References

• fetch.spec.whatwg.org/#x-content-type-options-header
• mimesniff.spec.whatwg.org/
• www.rfc-editor.org/rfc/rfc9110.html#name-content-type
• developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options
• cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html

x-content-type-options v1.0.0 Changelog

Initial release of the X-Content-Type-Options check.

This version evaluates:

• X-Content-Type-Options header presence
• Fetch-compatible first-value nosniff handling
• extra or malformed values
• scanned response Content-Type presence and plausibility
• sampled same-origin Chrome-observed responses when browser response evidence is available