将 Strict-Transport-Security header 添加到所有 HTTPS 响应?

Add Strict-Transport-Security header to all HTTPS responses?

在通读 https://hstspreload.org 时,我注意到 "Deployment Recommendations" 部分我应该 "Add the Strict-Transport-Security header to all HTTPS responses...".

因为在所有 https 响应中包含 HSTS-policy 对我来说听起来有些过分,我检查了一些网站以检查它们是否真的在所有 https 响应中都包含这个 header 字段。但甚至 google 都没有这样做,例如https://www.google.com/doodles 在响应中没有 Strict-Transport-Security header 字段。

所以我的问题是服务器响应什么时候应该包含 HSTS-policy?

我在这里看到的选项是:

  1. 在每个 https 响应中包含 HSTS。
  2. 在每个安全相关的 https 响应中包含 HSTS。
  3. 仅包括 HSTS,例如example.com 但不适用于示例中的任何路径。com/mypath
    • 我的意思是他们迟早会访问 example.com,不是吗?
  4. 仅当请求具有 "upgrade-insecure-requests: 1" 字段时才包含 HSTS
    • 我注意到如果未设置 HSTS,Chrome 会在安全相关内容中发送此请求 header 字段。

我认为将它添加到每个资源中并不过分。这是一个非常小的 header 并确保看到 HSTS 政策的最佳变化。

许多人甚至从基域加载像素(例如 www.example.com 可以加载 https://example.com/1pixel.png)以确保基域 HSTS 策略也被加载。如果您将 HSTS 配置为仅在文档上传递,则不会被提取。

我当然不会只在主页上包含它。说他们迟早会访问它并不是一个有效的假设。

你关心的是什么?您有一个超级优化的网站,如果为每个资源提供此 header 服务,它会被杀死吗?对于 CSP,我能理解你的想法,因为 header 可能会变得非常大,但对于 HSTS,我真的认为你想多了。此外,如果使用 HTTP/2,则 header 压缩也可以解决此问题。此外,在某些资源上只需要 return 的配置会增加您并不真正需要的复杂性和麻烦。