使用 no-transform 和 HTTPS 限制代理内容改写

使用 no-transform 声明 HTTP 内容策略，并使用 HTTPS 保护浏览器连接免遭传输途中的页面修改。

执行内容转换的代理可能会在响应发往浏览器的途中将其修改：重新压缩图像、改写标记或插入辅助 JavaScript。一个网络里正常、另一个网络里却出现陌生标记的页面，可能正遇到这种中间设备行为。

对于你运营的站点，HTTP 提供了明确的响应指令：

Cache-Control: no-transform

RFC 9111 要求收到该响应指令的中间设备保持内容不被转换，无论该中间设备是否实现缓存。这与图像重新压缩和标记注入有关，而不只是对象是否被存储。

与现有缓存策略一并保留

如果响应已有缓存指令，应有意识地添加该要求，而不是丢弃策略的其余部分。例如，可公开缓存的资源可能带有：

Cache-Control: public, max-age=3600, no-transform

该示例保留一小时的新鲜度策略，同时禁止内容转换。no-transform 并不意味着 no-store，也不会禁用常规传输处理。应把它设置在原始内容重要的响应上，包括在适当情况下单独设置的图像响应。

该指令依靠中间设备遵守来生效。它并不能在密码学层面阻止网络设备忽略该指示。

同时保护传输

HTTPS 为浏览器提供一条到其 TLS 对端、具备身份验证与完整性保护的连接。普通运营商代理在转发加密流量时无法悄悄向该受保护连接插入脚本。请保持证书验证开启；在本地受信任、终止 TLS 的检查代理属于另一种部署方式。

通过 HTTPS 提供页面及其依赖资源。将 HTTP 访问者重定向到 HTTPS，并对能够持续支持的部署考虑 HSTS。仅重定向对使用 HTTP URL 的访问者而言仍以未受保护的 HTTP 交换开始；此前学到或预加载的 HSTS 策略会改变这一初始选择。

阻止被注入的脚本可以减少其可见影响，但响应中可能已包含被修改的 HTML 或被改写的图像 URL。替换一个旧函数名、添加异常注释或映射历史注入地址，并不能为下一个中间设备确立内容完整性。

调查报告时，请将收到的响应与源站的预期内容进行比对，并确定 TLS 在何处终止。相比把每个陌生脚本都当作站点自身应用代码的缺陷，这些证据更有用。

相关文章