Artifactory的"Allow content browsing"功能是否发生变更或被禁用？

该问题是Artifactory版本迭代带来的默认安全策略变更导致的。从7.18.x版本开始，Artifactory为了降低恶意HTML文件带来的XSS攻击风险，默认对所有仓库的HTML类资源调整了返回规则：一方面默认将.html/.htm文件的MIME类型设置为application/octet-stream，另一方面会强制添加X-Content-Type-Options: nosniff响应头，导致浏览器识别为二进制文件直接触发下载，而非渲染展示，和「Allow content browsing」功能本身的开关状态无关。

• 首先配置目标仓库的MIME类型映射：进入对应存放HTML文档的仓库设置页，找到MIME类型配置模块，添加规则：将.html、.htm后缀对应的MIME类型设置为text/html，如果需要同时支持css、js等静态资源渲染，可同步添加对应后缀的标准MIME类型映射。
• 其次调整安全响应头规则：进入管理员面板的「安全>HTTP设置」页面，你可以根据安全要求二选一：
  • 方案一（安全性较低，操作简单）：全局关闭X-Content-Type-Options响应头
  • 方案二（更推荐）：保留全局响应头规则，单独将存放HTML文档的仓库路径添加到该响应头的排除列表中
• 如果你在Artifactory前部署了Nginx等反向代理，需要额外检查代理配置：确认没有给对应路径的资源强制添加Content-Disposition: attachment头，也没有修改HTML类资源的MIME类型，如有相关规则同步调整即可。
• 所有配置修改完成后，清空Artifactory服务端缓存和浏览器本地缓存，重新访问HTML资源即可恢复预览效果。

注意：开放HTML直接渲染会提升XSS攻击风险，建议仅对存放可信内部文档的私有仓库开启该配置，不要对外网可访问的公开仓库开放该能力。

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