flawopen.com/XSS/Content-type sniffing

Is content-type sniffing a hidden XSS risk?

Reference page — draft, pending review
Short answer

Yes. If a server doesn't declare a strict content type, some browsers try to guess ("sniff") what a file actually is from its content — and can decide to render a file you intended as plain text or an image as HTML instead, executing any script it contains.

A concrete scenario

An app lets users upload files and serves them back with a generic or missing Content-Type header. An attacker uploads a file that starts with HTML-looking content but has a .txt or image extension. A browser doing content sniffing may render it as HTML anyway, running any embedded script — even though the server never intended for that file to be treated as a web page.

The fix

RISKY — no explicit type declared
// server omits Content-Type or sends
// application/octet-stream with no
// nosniff header
SAFE — explicit header set
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff

The X-Content-Type-Options: nosniff response header tells the browser to trust the declared Content-Type exactly and never guess — this closes the sniffing-based execution path regardless of what the file actually contains.

FAQ

Does this only matter for file uploads?

It matters most there, but any endpoint returning user-influenced content without an explicit, correct Content-Type header and nosniff is exposed to the same risk.

References