.NET Core网站添加X-Content-Type-Options后返回页面源码求助

疑问分析 #

1. 页面显示源码的原因 #

没错，就是因为响应里丢失了Content-Type: text/html头导致的。浏览器拿到没有明确类型的内容，再加上X-Content-Type-Options: nosniff禁止MIME嗅探，就只能把内容当作纯文本渲染，自然就直接显示页面源码了。

2. 为何设置X-Content-Type-Options会引发该问题 #

在.NET Core通过IIS托管的场景下，web.config里的customHeaders配置如果写法有误，很容易覆盖或清除默认的Content-Type头，而非单纯追加新的头信息。常见的问题是不小心使用了clear指令，或者配置时破坏了IIS默认头的继承逻辑。

比如如果你的配置是这样：

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
  </customHeaders>
</httpProtocol>

本身写法没问题，但如果之前存在clear操作、误删了默认头配置，或者自定义中间件和web.config的头配置冲突，都会导致Content-Type头丢失。

解决办法 #

• 检查web.config的customHeaders配置，避免使用clear指令（除非你明确要清空所有默认头），直接追加新头即可：

<httpProtocol>
  <customHeaders>
    <!-- 仅添加安全头，保留默认的Content-Type头 -->
    <add name="X-Content-Type-Options" value="nosniff" />
  </customHeaders>
</httpProtocol>

• 如果上述方法无效，改用.NET Core代码中间件添加该头，绕开IIS配置的潜在冲突：

app.Use(async (context, next) =>
{
    context.Response.Headers.Append("X-Content-Type-Options", "nosniff");
    await next();
});

• 同时排查你的应用代码，确认没有自定义中间件或过滤器意外移除了Content-Type头。

验证方式 #

修改配置后重启网站，在Chrome DevTools的「网络」面板中查看响应头，确认同时存在以下两个头：

• Content-Type: text/html; charset=utf-8
• X-Content-Type-Options: nosniff

这样就能保证页面正常渲染，同时禁用MIME类型嗅探，满足安全测试要求。

内容的提问来源于stack exchange，提问作者anotherWebDev