禁用敏感http头比事后清理更有效，应通过iis的web.config禁用options方法并移除server、x-powered-by等泄露头，同时主动配置hsts、x-content-type-options、csp等安全响应头以防御常见攻击。
直接禁用或过滤敏感HTTP头，比事后清理更有效。关键不是“堵住所有出口”，而是控制哪些信息该对外可见。
禁用OPTIONS方法暴露服务器指纹
OPTIONS请求会返回Allow头部，列出服务器支持的所有HTTP方法（如GET、POST、PUT、TRACE等），还常附带Server、X-Powered-By等字段。攻击者可据此识别IIS/ASP.NET版本、中间件类型，甚至推测后端框架漏洞。
在IIS中，只需修改网站根目录下的web.config文件，在<system.webserver></system.webserver>节点内添加：
<security><requestfiltering><verbs allowunlisted="false"><add verb="GET" allowed="true"></add><add verb="HEAD" allowed="true"></add><add verb="POST" allowed="true"></add><add verb="PUT" allowed="true"></add><add verb="DELETE" allowed="true"></add><add verb="OPTIONS" allowed="false"></add></verbs></requestfiltering></security>
保存后重启站点或等待配置热加载即可生效。注意：禁用OPTIONS不影响浏览器跨域预检——现代浏览器仍会发送OPTIONS，但服务器不再响应，预检失败时自动降级为简单请求（只要满足CORS简单请求条件）。
精简并隐藏响应头中的敏感标识
默认的Server、X-Powered-By、X-AspNet-Version等头是典型的信息泄露源。它们不提供业务价值，只增加攻击面。
- IIS中可在
web.config里用<customheaders></customheaders>移除：<httpprotocol><customheaders><remove name="X-Powered-By"></remove><remove name="X-AspNet-Version"></remove></customheaders></httpprotocol>
- 若使用URL重写模块，还可彻底屏蔽
Server头（需配合注册表修改或Application Request Routing） - Tomcat用户应在
conf/server.xml中设置server=" "和suppressStackTraces="true"
主动设置安全响应头防御常见攻击
不是“防止泄露”，而是“提前加固”。以下头部应作为标配写入响应：
-
Strict-Transport-Security：强制HTTPS，防降级攻击
max-age=31536000; includeSubDomains; preload -
X-Content-Type-Options：禁止MIME嗅探，防资源误解析执行
nosniff -
X-Frame-Options 或 Content-Security-Policy：防点击劫持
推荐用CSP：frame-ancestors 'none'（更现代、兼容性更好） -
Referrer-Policy：控制Referer字段携带信息量
生产环境建议：strict-origin-when-cross-origin，兼顾功能与隐私
验证是否生效的实操方式
别依赖截图或主观判断，用命令行快速验证：
- 检查OPTIONS是否被禁用：
curl -X OPTIONS https://yoursite.com -I | grep Allow
返回空或405即成功 - 查看响应头是否精简：
curl -I https://yoursite.com | grep -E "(Server|X-Powered-By|X-AspNet)"
不应有任何输出 - 确认安全头已注入：
curl -I https://yoursite.com | grep -E "(Strict-Transport-Security|X-Content-Type-Options|Content-Security-Policy)"
每次上线前跑一遍这三行命令，5分钟完成基础头安全闭环。
