【问题标题】:Add Strict-Transport-Security header to all HTTPS responses?将 Strict-Transport-Security 标头添加到所有 HTTPS 响应?
【发布时间】:2019-03-07 05:46:16
【问题描述】:

在阅读https://hstspreload.org 时,我注意到在“部署建议”部分中我应该“将 Strict-Transport-Security 标头添加到所有 HTTPS 响应...”

由于在所有 https 响应中包含 HSTS-policy 对我来说听起来有点矫枉过正,我检查了一些网站以检查它们是否真的在所有 https 响应中都包含此标头字段。但即使是谷歌也没有这样做,例如https://www.google.com/doodles 在响应中没有 Strict-Transport-Security 标头字段。

所以我的问题是服务器响应何时应该包含 HSTS 策略?

我在这里看到的选项是:

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

【问题讨论】:

    标签: http https hsts


    【解决方案1】:

    我认为将它添加到每个资源中并不过分。这是一个非常小的标头,可确保看到 HSTS 策略的最佳更改。

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

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

    您对此有何顾虑?您有一个超级优化的站点,该站点将通过为每个资源提供此标头而被杀死?对于 CSP,我会理解您的来源,因为该标头可能会变得非常大,但对于 HSTS,我真的认为您想多了。此外,如果使用 HTTP/2,那么标头压缩也可以解决此问题。此外,仅在某些资源上返回它所需的配置会增加复杂性和您并不真正需要的麻烦。

    【讨论】:

    • 感谢您的回答!过度杀伤可能不是正确的词,你是对的。尽管如此,如果您将所有资源都考虑在内,例如样式表、图片以及 ajax 等……您最终会在每个 html 页面调用中产生几 kb 的开销。这不值得优化吗?
    • 不值得考虑,你说得对!开销百分比很低。感谢您的宝贵时间!
    猜你喜欢
    • 2016-07-12
    • 1970-01-01
    • 2014-09-29
    • 2015-04-06
    • 1970-01-01
    • 2019-05-17
    • 2018-04-05
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多