想象一个服务，它只通过 HTTPS 在秘密 URL 下提供敏感信息，而不需要任何其他身份验证。事实上，这些已经很普遍了。
与使用保存在浏览器中的用户名/密码的传统 HTTPS 登录表单相比，这提供了什么级别的安全性？
浏览器是否会泄漏 HTTPS URL（当然，除非存在未发现的漏洞），还是理论上它与运行浏览器的机器上的本地文件一样安全？
泄漏向量示例：Firefox 崩溃报告器；Chrome 即用型查找；IE 恶意软件保护服务。所有这些都可能将 URL 泄露给第三方。HTTPS URL 是否安全？
在HTTPS中，实际 URL 仅在执行 SSL 握手后发送。外人可以观察到的是：
“秘密 URL”的一个潜在问题是它们可以被用户添加书签或复制（例如通过电子邮件发送），并且还显示在用户屏幕上（在 URL 栏中），因此可能容易受到肩冲浪者的攻击。对于密码和安全 cookie（由带有“安全”标志的服务器发送的 cookie），所涉及的应用程序（即浏览器）应该比 URL 更加谨慎。与密码相比，人类用户对 URL 的谨慎程度也稍低。总的来说，秘密 URL 是一种有效的安全机制，但您必须注意细节。
与使用保存在浏览器中的用户名/密码的传统 HTTPS 登录表单相比，这提供了什么级别的安全性？
正如您从其他答案中收集的那样，HTTPS 隐藏了实际请求本身。连接到服务器时不会发送完整的 URL - url 的文档部分设置为如下所示的请求：
GET /login/reallysecure/thisismypassword
或更传统的：
POST /login
稍后在 HTTP 请求中以纯格式或作为多部分 mime 主体的一部分发送 POST 参数。
您可能没有想到的一个考虑因素是 url 访问通常由网络服务器记录，这意味着在任何时间点您都会说 3 天（根据您的日志保留策略进行调整）的用户名登录值距离您的系统一个 grep管理员。虽然这可以说是无关紧要的，因为对应用程序本身的修改可以毫不费力地转储普通的登录凭据，但现在有一个额外的保护因素 - 你备份你的日志吗？如果这些被盗怎么办？
更糟糕的是，如果有办法操纵您的服务器将日志返回给外部客户端，会发生什么？这是对安全性的巨大破坏，但与返回密码数据库不同，该数据库希望使用良好的散列技术来减轻（并且非常减轻）这种影响，URL 没有相同的保护 - 它只是即时的访问相关帐户。
这是 Thomas 已经强调的客户端风险的服务器端。
明文 URL 可能会存储在浏览器的历史记录和缓存文件中，但 URL 本身不会通过网络以明文形式传输，因为 SSL 会话在发送任何 HTTP 流量之前就开始了。
另一个旁道是 HTTPS 页面中的任何非 HTTPS 内容都可能导致主页的 URL 通过引用标头泄露。 原来前面是假的。Referer 不会从 HTTPS 页面发送到 HTTP 页面。