在阅读 HSTS(严格传输安全)规范时，我在 section 7.2 中看到一条禁令。禁止在通过 http 而不是 https 访问时发送 header :
An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.
这是为什么呢？如果违反的话会有什么风险？
最佳答案
不确定您是否有想要解决的特定问题，或者只是出于好奇而询问，但这可能更好地在 http://security.stackexchange.com 上询问。
和你一样，我看不到来自通过 HTTP 发送此信息的服务器的威胁。这确实没有意义，但说实话我不确定是否存在风险。除非说如果您无法正确设置 header ，那么您可能还没有准备好实现 HSTS，因为如果配置错误，可能会很危险!
更大的危险是浏览器是否要处理通过 HTTP 接收的 HSTS header ，第 8.1 节明确指出它必须忽略:
If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).
这里的风险是，如果浏览器错误地处理了纯 HTTP 网站(或混合网站的纯 HTTP 部分)，恶意攻击者(或意外配置错误的 header )可能会使该网站脱机。这将有效地导致该用户遭受 DoS，直到 header 过期或站点实现 HTTPS。
此外，如果浏览器确实通过 HTTP 而不是 HTTPS 接受此 header ，MITM 攻击者可能会通过将 max-age 设置为 0 来使 header 过期。例如，如果您设置了很长的 HSTS header 上https://www.example.com但攻击者能够通过 includeSubDomain 发布 max-age=0 header http://example.com ，并且浏览器错误地处理了它，那么它可以有效地消除 HTTPS 为您的 www 站点提供的保护。
出于这些原因，客户端(即网络浏览器)正确实现这一点并在通过 HTTP 提供服务时忽略 HSTS header 并仅通过 HTTPS 处理它非常重要。这可能是 RFC 规定服务器不得通过 HTTP 发送此信息的另一个原因 - 以防浏览器实现此错误，但说实话，如果发生这种情况，那么该浏览器将使所有仅 HTTP 网站面临风险，因为 MITM 攻击者可能会添加如上所述。
关于security - 为什么 RFC 6797 禁止通过纯 HTTP 响应发送 Strict-Transport-Security header ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39712546/