我有一个没有 HSTS 的带有 SSL 的 Nginx。 但在后端，很少有服务不是 https。 启用 HSTS 是否有任何潜在风险？ 我担心当 HSTS 标头存在时，HSTS 标头会破坏内部路由，强制重定向到 HTTPS
例如
当前：
公众用户 -> https://www.123.com --- 内部服务 ---> Http://internalA.123.com -> Http://internalA.123.com
会变成下面吗？
公众用户->“https://www.123.com”---内部服务--->https://internalA.123.com->https://internalA.123.com
如果是，那么服务肯定会与HSTS中断
【问题讨论】：
HSTS 仅涉及客户端（浏览器）和 Web 服务器（nginx）之间的连接。服务器对接收到的数据做什么并不重要，即数据是在本地处理的，还是服务器只是某个其他服务器的反向代理。客户端和服务器之间的类似 HTTPS 仅保护这两者之间的通信，既不保护来自反向代理的任何进一步连接，也不保护服务器端的本地数据处理。
【讨论】：
HSTS 是从服务器 (nginx) 到客户端 (浏览器) 的指令，说“嘿，下次假设我在 HTTPS 上”。因此，在上述情况下，它不会像 Steffen 所说的那样用于后端连接。
但肯定有一些危险需要注意：
首先，如果您将其设置在顶级域（例如 123.com）并使用 includeSubDomains，那么 123.com 上的每个域都可能突然受到 HSTS 保护。这可能仍然不会影响您的后端连接，但是如果您碰巧在浏览器中访问 https://123.com（也许您只是在 URL 栏中输入）并选择该标题，然后尝试访问 http://intranet.123.com 或 http://dev.123.com 或即使http://dev.123.com:8080 然后它们都将重定向到 HTTPS，如果它们不能通过 HTTPS 使用，那么它们将失败，您将无法再访问这些站点。这可能很难追踪，因为可能没有多少人访问裸域，所以它“对我来说很好用”。
当然，如果您只在该域上的所有网站（包括所有内部网站）上使用 HTTPS，那么这不是问题，但如果不是......
作为额外的保护，您还可以将您的网站提交到预加载列表，然后在下一个版本中将其硬编码到浏览器中，并且其他一些客户端也使用此硬编码列表。这是一种额外的保护，尽管它带来了额外的风险，因为它的要求之一是顶级域包含在includeSubDomains 中。我知道你没有问过这个问题，但既然你问的是这个的风险，我认为这里值得一提。因此，通过预加载 HSTS，即使 没有 访问 https://123.com 来获取标题，它也会突然带来所有上述风险。而且，由于浏览器版本之间的间隔数月（甚至数年），这基本上是不可逆转的。您可以很高兴地在您的 www 域上运行 HSTS，认为一切正常并决定升级到预加载列表，因为您没有看到任何问题，突然随着下一个浏览器版本的发布，您所有仅 HTTP 的内部站点都停止了正常工作，您需要立即将它们全部升级为 HTTPS，否则无法访问。
总而言之，如果目前仍有一些仅使用 HTTP 的站点，请注意 HSTS。考虑只在需要它的网站上返回它（例如 https://123.com without includeSubdomains 和 https://www.123.com with includeSubdomains），并且在预加载它时要格外小心。就我个人而言，我认为预加载对于大多数网站来说都是多余的，但如果你真的想这样做，那么最好的做法是首先在你的主页上从 https://123.com 加载一个具有小过期时间的资源，然后慢慢增加它。这样每个人都会在将其提交到预加载列表之前将其选中，并且不会有任何意外。
但是 HSTS 很好，应该在所有面向公众的网站上使用恕我直言，我不希望这个答案让您失望 - 只需了解它的工作原理以及它的风险。
【讨论】：