How to set X-Content-Type-Options?

x-content-type-options-missingglobal

The X-Content-Type-Options header controls browser MIME type interpretation. Without this header, browsers may ignore the declared Content-Type and attempt to guess the file type from content. This behavior creates security risks when user-controlled content is served or when Content-Type headers are misconfigured.

What’s wrong

The response lacks the X-Content-Type-Options header. Browsers are permitted to perform MIME sniffing, where they inspect response content to determine file type independently of the Content-Type header. A file served as text/plain but containing HTML tags may be interpreted and executed as HTML. This interpretation mismatch enables attacks when Content-Type declarations are trusted but browser behavior differs.

Why it matters

MIME sniffing creates confusion between server intent and browser interpretation. A JSON endpoint incorrectly served as text/html becomes exploitable when browsers execute embedded scripts. User uploads saved as text/plain may render as HTML if sniffing detects markup. The server declares one type, the browser executes another. This gap undermines Content-Type as a security control.

The correct change

Add X-Content-Type-Options: nosniff to all responses. This instructs browsers to strictly follow the declared Content-Type without content inspection. The end state is alignment between server declaration and browser interpretation. Content-Type becomes reliable as both information and security boundary.

Scope

This condition applies globally. The header should be set at the server or application level for all responses. Individual resources cannot override without broader configuration. Assets, documents, and API responses all benefit from the same policy.

How to verify

• Validation confirms the condition is resolved:
• • X-Content-Type-Options: nosniff appears in response headers
• • Header is present on all response types including assets
• • Browsers do not execute content that differs from declared Content-Type
• • Security scanners confirm MIME sniffing protection is active
• • Content-Type mismatches surface as errors rather than silent reinterpretation
• • User-controlled content cannot bypass type restrictions through sniffing

Takeaway

• MIME sniffing allows browsers to override server Content-Type declarations
• X-Content-Type-Options: nosniff enforces strict type interpretation
• The header converts Content-Type from advisory to enforceable boundary
• Protection applies globally and should be set for all responses

FAQ

Does nosniff affect performance or caching?

No. The header affects only browser interpretation logic, not network behavior. Cache mechanisms continue operating normally. The header adds negligible overhead to response headers.

What happens when Content-Type is incorrect with nosniff active?

Browsers refuse to process the content. A JavaScript file served as text/html will not execute. This surfaces misconfigurations as errors rather than allowing silent reinterpretation. Correct operation requires accurate Content-Type declarations.

Can nosniff break existing functionality?

Only if the site relies on MIME sniffing to correct Content-Type errors. A stylesheet served as text/plain would previously load through sniffing. With nosniff, it fails. This failure indicates an existing misconfiguration that should be fixed at the source.

Does the header protect against all file upload attacks?

No. It prevents browsers from reinterpreting declared types. Other protections remain necessary: validating uploads, storing them outside web roots, serving them from separate domains, and setting correct Content-Type values. Nosniff is one control in a defense strategy.

Should nosniff be set for APIs that return JSON?

Yes. JSON APIs should declare Content-Type: application/json and include nosniff. This prevents browsers from treating JSON responses as HTML if they contain markup-like patterns. API responses become strictly typed.

How does nosniff interact with content security policy?

They address different risks. CSP restricts which resources can load and execute. Nosniff ensures browsers interpret resources according to declared type. Both headers work together. CSP controls policy, nosniff enforces type interpretation.

The fix

Prevent MIME sniffing by enforcing strict Content-Type interpretation

Done when: X-Content-Type-Options: nosniff is present on all responses, ensuring browsers respect declared Content-Type without content inspection

Do not

• Do not omit the header from specific content types assuming they are safe
• Do not use values other than nosniff, which is the only defined value
• Do not rely on nosniff to compensate for incorrect Content-Type declarations
• Do not assume the header is redundant if Content-Type is set correctly

How to verify

• X-Content-Type-Options: nosniff present in response headers
• Header applies to all response types
• Browsers enforce Content-Type strictly
• Content-Type mismatches cause errors
• Security scanners confirm MIME sniffing protection

Find every page with this

probeo monitors this continuously across every page of your site, and records which pages passed, which failed, and which it could not determine.