我刚刚偶然发现了 chrome 中一个非常有用的标志（对于开发人员）：
chrome://flags/#allow-insecure-localhost
该标志描述为：
Allow invalid certificates for resources loaded from localhost.
Allows requests to localhost over HTTPS even when an invalid certificate is presented. – Mac, Windows, Linux, Chrome OS, Android
总是必须为多种服务生成自签名证书，这很好，但它引出了问题——这安全吗？一直开着这样安全吗？
如果这不安全，可能的攻击是什么？
在某些情况下，您希望localhost使用 HTTPS 进行通信 - 例如运行本地 Web 服务器以进行 Web 开发或提供 Web 界面的其他服务。
“正确”执行此操作的方法是生成一个自签名证书，设置您的 Web 服务器以使用该证书，然后将该证书手动导入为受信任的证书。这是一个乏味的过程，为了消除这种摩擦，浏览器让您可以选择假装https://localhost正在发送一些受信任的证书，即使事实并非如此。
那么这安全吗？这取决于您的威胁模型。对于日常浏览活动，您可能会没事。即使在您的本地网络中，攻击者也很难冒充localhost，因为它直接写入您的 hosts 文件中，在大多数设置中，该文件的优先级高于 DNS - 这意味着即使使用受损的 DNS 服务器，到的连接localhost仍然不会重定向到攻击者。
那么，如果它最有可能是安全的，为什么这不是默认设置呢？因为这不是浏览器的“预期”行为。预期的行为是，在使用 HTTPS 连接到主机时，证书会被验证，如果证书无效，则连接会被拒绝。作为最终用户，您必须做出有意识的决定来更改此行为并允许此异常。
那么什么时候会不安全呢？它何时会真正构成威胁？老实说，我很难想出一个不是完全人为的例子。奇怪的主机名解析配置，其中localhost将通过 DNS 解析并伪装成某个主机，而不是127.0.0.1想到的，但这是一种非常不可能的情况，并且用户必须不遗余力地将他们的系统配置为变得脆弱。但是，我不想说“在所有可能的设置中都非常好”，因为我总是有可能遗漏一些东西。
类似的情况是颁发证书（例如，来自内部公司 CA）
dNSName = localhost
iPAddress = 127.0.0.1
我怀疑任何受公众信任的 CA 都会为 颁发证书localhost，因此可能需要这样的设置来消除证书错误？（假设您不想将证书添加到您的信任库中，这是一个更大的风险）。
我还没有遇到过这种危险的情况。即我能想到的任何攻击都要求攻击者已经在受害者的计算机上运行代码。
我想一个警告是，如果您在托管本地网络服务器的计算机上安装了许多应用程序（胖客户端），以便浏览器可以与它们交互。例如，想象一个胖客户端，mikesgames.com它可以让浏览器游戏直接访问您的 USB 设备。如果您信任该应用程序并且知道它就在那里，那很好，但是很难正确保护该本地服务，因此您可能会打开任何随机网站来检查这个胖客户端，然后控制您的 USB 设备。我特别被随机网站探测localhost以查看您正在侦听的端口并从那里找出您安装了哪些胖客户端的想法所困扰。
我希望浏览器默认阻止localhost与弹出窗口的任何连接“你想允许 mikesgames.com 与你机器上的应用程序通信吗？” . 如果单击“是”，我认为对于这些本地主机连接，http、带有无效证书的 https、带有有效证书的 https 之间没有太大的安全差异。您可能希望应用程序供应商有办法让网站和胖客户端相互验证，以防止其他站点滥用胖客户端，但这确实超出了浏览器设置的范围。