为什么 google.com 没有在 http 严格传输安全响应标头上设置 includeSubDomains 指令？
google.com HSTS 响应标头类似于：
Strict-Transport-Security:max-age=86400
为什么不
Strict-Transport-Security: max-age=86400; includeSubDomains
第二个对我来说应该更安全，对吗？？
【问题讨论】：
标签： http security httpresponse hsts
它是静态的
使用谷歌浏览器，您可以转到chrome://net-internals/#hsts 并查询不同的域。输入google.com 并单击查询将返回结果列表。
在该结果列表中，您可以看到 static_sts_include_subdomains 为真，dynamic_sts_include_subdomains 为假。这比动态设置要好，因为动态设置很容易受到攻击，即浏览器第一次使用http://（不是https://）请求域时，对手会拦截通信。为了克服这个弱点，我们有静态模式，它允许将 HSTS 记录直接硬编码到浏览器的源代码中。
希望对你有帮助
【讨论】：
preload 标志表示网站所有者同意预加载其域。站点所有者仍然需要然后将域提交到列表中。谷歌还在第一次连接上运行重定向。需要额外的重定向以确保任何支持 HSTS 的浏览器都会记录顶级域的 HSTS 条目，而不仅仅是子域。
是的，使用includeSubDomains 更安全。
例如，攻击者可以设置和使用子域（例如 hacked.google.com）并通过 HTTP 访问该子域，并使用该子域访问或覆盖在顶级域 (google.com) 中设置的 cookie，即使该顶级域级别域由 HSTS 保护。当然，如果您在 cookie 上使用 Secure 属性，那么这可能不是问题，但这只是为什么要使用 includeSubDomains 的一个示例。
您不能设置includeSubDomains 属性，除非所有子域都在 HTTPS 上可用（显然）。因此，如果 Google 拥有 blog.google.com，但仍未将其升级到 HTTPS，那么这或许可以解释为什么他们不会在顶级域中使用 includeSubDomains。
但是，正如 @Horkine 正确指出的那样，Google 将其域预加载到 Chrome 浏览器代码中（并且该预加载列表也被其他浏览器拾取），因此该 HTTP 标头不适用于现代浏览器。
奇怪的是，预加载版本和 HTTP HTTP 标头版本之间存在一些不一致之处。老实说，这很奇怪。顺便说一句，这些差异也有breaks their own rules for preloading。
www.google.com
includeSubDomains 属性。includeSubDomains 属性，但没有preload 属性。google.com
includeSubDomains 属性为什么会出现这些不一致？我们只能猜测：
可能是他们在完成所有网站的升级后从未有时间更新其 HTTP 标头？
或者可能是因为某些应用程序对旧浏览器进行浏览器检测（不包括预加载代码，但确实理解 HSTS 标头）并将旧浏览器重定向到 http://old.google.com 出于某种原因？
或者它可能是特定于区域的？
所有这些都是猜测，因为只有 Google 可以回答，我不知道他们在自己的网站上使用什么或为什么使用的任何文档。
但是，是的，要回答您最后一个问题，包含includeSubDomains（如果可能）更安全，并且预加载更安全（尽管并非没有风险，除非您 100% 确信您只使用 HTTPS） .
【讨论】：