MIME sniffing is one of those security issues that feels invisible until it suddenly isn’t. Your API can return “valid JSON” all day long — but if the browser is allowed to guess the content type, it may reinterpret the response as something executable. Nothing crashes. Nothing looks broken. And that’s exactly why this issue survives.
What was tested
A normal API response where a single security header should be present by default.
Rentgen checks whether the server disables MIME sniffing by sending
X-Content-Type-Options: nosniff.
This forces browsers to respect the declared Content-Type instead of trying to “figure it out”.
What Rentgen found
- Missing X-Content-Type-Options (nosniff not set)
- Result: the browser may “sniff” the response body and treat it as HTML/JS instead of what the API intended
- Severity: 🔴 Fail — because this enables real, browser-exploitable attack classes
Why it’s a fail (not a warning)
Because this isn’t a “nice to have” header. Without nosniff, you’re letting the client reinterpret your data.
That opens the door to content-type confusion and XSS-style exploitation paths — especially when responses contain
user-controlled values, error messages, or anything that can be influenced by input.
Teams often say: “But it’s just an API.” And that’s how it slips through. Modern APIs are frequently consumed directly from browsers (SPAs), share domains with frontend assets, and return content that gets rendered or processed in a user context. MIME sniffing doesn’t care about your architecture diagram.
That’s why Rentgen marks it as 🔴 Fail: it’s a baseline defense you either have or you don’t. There’s no meaningful upside to leaving it out — and the cost to add it is almost zero.
Final thoughts
People don’t forget hard security work. They forget simple headers.
X-Content-Type-Options: nosniff is a one-line fix that prevents a whole category of “browser got creative” problems.
Rentgen fails this check so it becomes a default habit — not a future incident footnote.