建议在每个 HTTPS 响应上设置 HSTS 标头，但这有效地提供了相同级别的安全性，因为 HSTS 策略被缓存了max-age几秒钟。它定义了缺少Strict-Transport-Security标头不会导致策略的删除，而只会为（max-age RFC 6796 6.1.1、5.3和12.5 ）设置零值。此外，将值设置得太低会导致它过早过期。

max-age这些设置可以在几秒钟内保护访问过受信任网络上的页面（或者浏览器看到其上的 HSTS 标头，更准确地说）的用户。如果在每次访问时都加载提供 HSTS 标头的 URL，那么这并不会真正影响这一点。尽管如此，我看不出有任何理由不在主机名级别上移动此配置，而且这也可能只是一个错误。

但是，这会阻止在用户访问该站点之前保护用户（这将是下一步和级别），因为如果您希望将域添加Strict-Transport-Security到HSTS Pre -加载列表。这是提前保护整个,等的唯一方法。此外，hstspreload.org要求 max-age 必须至少为秒（1 年）。includeSubDomainspreload/example.com*.example.com*.*.example.com31536000

看起来确实很奇怪。这里有两个场景来说明。

情景一

也许浏览器设置可能不加载资产，例如移动数据上的移动设备，其中可能不加载资产以节省带宽。

然后，您将对 HSTS 所防御的所有漏洞持开放态度。

场景二 （这个场景在下面的评论中讨论后编辑）

此外，即使没有对资产加载的这种限制，也没有索引页面的 HSTS 标头，您的 Web 应用程序也会受到攻击，其结果是攻击者可能已经成功地将初始响应替换为任意页面他们选择，通过http。如果在加载索引页面时发生这种情况，那么接下来应该发生的任何资产加载都变得无关紧要，因此您的浏览器甚至永远不会请求这些资产，也永远不会在响应中看到 HSTS 标头。

作为一个具体的例子，考虑一个 SSL 剥离中间人 (MiTM) 攻击。在 SSL 剥离中间人攻击中，中间人将 https 连接转换为 http。现在，如何防止攻击者简单地忽略来自您的 Web 应用程序的响应的 HSTS 标头，并通过没有 HSTS 标头的 http 将他们的任意响应呈现给客户端？这就是预加载列表出现的地方。

所有主要浏览器都实现了 HSTS 预加载列表，其中包括支持 HSTS 的已知站点。因此，浏览器不必依赖从站点接收实际响应来知道它实现了 HSTS，因此浏览器将强制使用 https。那么，这些 HSTS 预加载列表是如何生成供浏览器使用的呢？

以 firefox 为例（参见blog.mozilla.org/security），

为了构建我们的预加载列表，向 Chrome 列表中带有“模式：“force-https””的每个主机发送一个请求。仅当主机以有效的 HSTS 标头响应时..

因此，在 Web 应用程序的索引页面中不包含 HSTS 标头可能会导致它被排除在预加载列表之外，从而使 Web 应用程序容易受到 HSTS（通过预加载列表实现）通常可以防御的攻击。