是否值得将 CSP 标头与 HSTS 标头进行比较？答案

【问题标题】：Is it worth comparing CSP headers with HSTS headers?是否值得将 CSP 标头与 HSTS 标头进行比较？
【发布时间】：2015-09-29 18:30:38
【问题描述】：

我正在开发一个将 HSTS 标头添加到 Web 应用程序的项目。
作为为此的准备工作，我仅使用 default-src https 指令在报告模式下添加了 CSP 标头。目的是评估违规行为并确定添加 HSTS 标头是否会破坏任何用例。
问题：

这是一个值得的方法吗？
使用这种方法，我们会错过哪些 HSTS 场景？
如果它们与我上面描述的不同，推荐的方法是什么？

【问题讨论】：

标签： hsts

【解决方案1】：

如果您仅在服务器上使用 https，我会认为这很明显。你有设置https吗？您是否设置了重定向以强制将所有 http 请求重定向到 https？这些问题应该很容易通过查看您的服务器配置来回答，我认为您不需要 CSP 来回答这些问题。如果两者的答案都不是“是”，那么您为什么要考虑 HSTS？

CSP 支持不是通用的（尽管公认 HSTS 也不是），并且，对于这些东西，通常会损坏的是较旧的、不太常见的浏览器，因为您可能会测试常见的浏览器，因此您的方法是否会给您信心你需要继续是有争议的。

您应该注意的一件事是您是否使用了 includeSubDomains 标志。如果它影响的服务器数量超出您的预期，这可能会导致问题，但 CSP 无济于事，因为您可能只会在您认为会受到影响的服务器上设置 CSP。更多信息在这里：https://serverfault.com/questions/665234/problems-using-hsts-header-at-top-level-domain-with-includesubdomains。

另外请注意，一旦实施 HSTS，就不能再在浏览器中绕过证书错误。不是说你应该这样做，而是这个标志的另一个不是每个人都知道的故意效果。

请注意，解决 HSTS 问题的唯一方法（例如，如果您发现您毕竟需要 http），除了删除标头并等待策略过期之外，是将最大年龄设置回零并希望人们使用 https 访问您的网站以获取此新的 HSTS 政策并覆盖之前的政策。使用 Chrome 可以手动查看和删除策略，但如果您有大量访问者并且不知道在没有完全重新安装的情况下使用其他浏览器执行此操作的任何方法，那么这是不切实际的。

最好的方法是充分了解 HSTS 是什么以及上述注意事项，然后从低到期日开始，只要您没有遇到任何问题，就慢慢建立它。

还有预加载列表，但我会远离它，直到您运行该列表至少 6 个月没有问题。

【讨论】：

在这种情况下，HSTS 不会破坏您的网站，因为您已经在 https 上（请注意我上面提到的任何子域的 includeSubDomains 问题）。然而，即使是 http 链接也会被自动重定向，因此 CSP 不会报告任何内容 - 除非您通过 http 在您的网站上加载第 3 方内容，这会导致您出现其他错误，并且 HSTS 无济于事（除了小用例完全限定的 http 链接返回到您自己的站点）。 HSTS 负责处理请求。 CSP 负责页面上加载的内容。两个几乎没有重叠的不同用例。
您的两个问题的答案都是肯定的。让我试着重新表述我的问题。通过应用标头类似于以下内容的 CSP 策略来使用 CSP 评估 HSTS 是否很好：Content-Security-Policy-Report-Only: default-src https:;脚本源 https: 'unsafe-inline' 'unsafe-eval'; style-src https: '不安全的内联'; img-src https: 数据:; font-src https: 数据:; report-uri 我会调查你提到的点 - 与证书错误有关。