明智的做法是始终强制使用 HTTP 严格传输安全 (HSTS) 标头，因为不加密的风险可能会更大。

在这种特殊情况下，它是机密性和可用性之间的直接权衡。对于大多数但并非所有企业而言，保密更为重要。

如果您的企业更重视机密性而不是可用性，那么如果可用性更重要，则强制使用 HSTS，然后不要。

如果您的开发团队容易在负载均衡器后面的服务器上出现糟糕的安全配置，HSTS 也特别有用。HSTS 允许组织强制执行 https，这通常是一件非常好的事情。

注意：一般来说，在负载平衡器上而不是在网络服务器层这样做还有一个隐藏的好处。如果负载平衡器使用 HSTS 标头进行响应，它实际上减少了其背后系统的一些负载，并减少了站点到 https 页面的往返页面加载。这会少量减少网络服务器的负载，对于某些攻击，这实际上会增加攻击者的工作量。

供参考：https : //www.rfc-editor.org/rfc/rfc6797

简短的回答：这并不重要。更长的答案如下。

什么是HSTS？

HSTS 或 HTTP 严格传输安全性是一个 HTTP 响应标头，可以为 Web 浏览器设置以强制 TLS 连接。典型的标头如下所示：

Strict-Transport-Security: max-age=31536000; includeSubDomains

但是，仅此标头不会加密通信。

此标头必须通过 TLS 连接发送才能生效。

TLS 连接

TLS 连接或更通用的 HTTPS 对传输中的浏览器到服务器的通信进行加密并提供完整性检查。通过利用 HSTS，它是一种增强功能，它告诉浏览器永远不要尝试连接到纯 HTTP。这是确保仅通过 HTTPS 进行通信的附加方法。

加法方法是什么意思？

这里的意思是基线是 HTTPS。这是在 HSTS 和其他方法甚至可以考虑之前的要求。大多数人，包括我自己，都没有输入的习惯https://www.example.com，而是输入www.example.com或只是输入example.com，我们希望服务器能够处理从 HTTP 到 HTTPS 的重定向。这种可用性引入​​了在受害者从 HTTP 重定向到 HTTPS 之前修改 cookie 和其他数据的机会。HSTS 试图通过告诉浏览器永远不要转到 HTTP 而只是转到 HTTPS 来解决这个问题。

securecookie 中的标志告诉浏览器不要通过 HTTP 发送这些 cookie，而只通过 HTTPS 发送它们。这可以防止诸如SSLStrip获取 cookie 数据之类的攻击工具。HSTS 在安全标志之上添加了另一层，并告诉浏览器除了永远不要通过 HTTP 发送 cookie 之外，永远不要通过 HTTP 发送任何数据。

你的食谱看起来像这样：

TLS: - Secure flag on cookies - HSTS

除非您的公司政策要求，否则安全通信不需要 HSTS。

分布式拒绝服务

攻击者寻找 404 或其他响应的情况并不是什么大问题，因为攻击者可以简单地发出对导致 200 个响应代码的页面的请求。

我在回复开始时说这并不重要。原因是在 LB 上写入响应标头无论如何都会发生在非 404 页面上，因此所描述的 DDoS 情况不会是我关心的问题。