所以你的问题提出了一些我希望我知道更多的观点，但我会尽力至少把事情弄清楚......
您的浏览器正在缓存路径中包含私人/安全信息的 URL，从而为您的私人信息留给其他人的潜在窗口。影响：
- 当您不在时，有人可能会走到您的计算机前，或者可能远程访问您的计算机，或者——如果没有在多个级别上采取适当的预防措施——使用 XSS 方法通过 javascript 获取缓存的 URL。
这种担忧是合法的，但您已经指出可以采取哪些步骤来消除它们：
不要打开多个窗口，一些私人的，一些不那么私人的。使用私人浏览器会话进行私人浏览。实际上，我有一个 Firefox 插件的想法，它可以让你创建一个“黑名单”，一个应该始终处于隐身模式的域列表。这样你就可以在你的银行网站上，跳到 twitter，它知道有不同的会话，等等。
将您的浏览器设置为在每次关闭时删除（或至少要求删除）所有个人数据。
在服务器端，任何负责任的 Web 应用程序设计者都不应在URL中使用凭据或个人数据来建立安全站点。那不是光滑，那是懒惰。我认为 ID 号或会话 ID 并没有好多少（我将在第二点讨论）。您的银行应使用：/onlinebanking/UserServices/transactions作为 RESTful url，并且应该在服务器级别确认每个请求的所有内容，直至 IP（mod_auth 和该死的好证书）。听到人们谈论“减少服务器负载”甚至“减少数据库命中”，我感到非常疲惫。该软件专为接收大量请求而设计。我 6 年前制造的 HP 笔记本电脑听起来像是一台旧冰箱，并不是为了减轻服务器的工作量而设计的，等待 10 分钟等待一个设计不佳的 js 脚本（请参阅：新的 Yahoo! Mail 客户端）让我想刺伤。如果不应该期望可怜的被滥用的巨型服务器处理其他任何事情，那么它应该每次都确保您的安全。
好了，吐槽结束了。
- 你的兄弟能看到你缓存的网址吗？也许。即使我清除了历史记录，我的女朋友也可以知道我何时访问了 xxx 网站（为什么？因为它仍然显示在最近关闭的标签中！耶隐私！）而且那些没有被缓存用于 RESTful，它们正在被缓存因为这就是浏览器所做的。因此，在访问 URL 中包含的站点后，您应该采取相同的预防措施，
iamgoingtokillhimtonight/posts就像您在访问 pron 站点或查找生日礼物的想法时一样。
关于我的解释的一部分：
所以是的，这些 URL 被缓存了，这对于任何想要细读所述缓存以进入您的业务的人来说都是令人毛骨悚然的。但似乎您表达的另一个问题是他们可以用它做什么，即跨浏览器利用。有人可以使用该缓存的 URL 编写脚本来获取您的实际银行信息并消灭您吗？是的。但是，如果他们已经知道如何做到这一点，他们获得的优势是微不足道的。这更像是为他们节省了一步，然后将钥匙挂在门上。如果我能以某种方式通过 js 看到您的缓存，从而看到您的安全银行 URL，那么如果他们不使用可爱的 URL，我可以很容易地看到您的银行的 URL，并且可以很容易地围绕它编写我的 XSS。如果我能看到你的缓存，我肯定能看到你的 cookie 并窃取它们（只有在网络上 cookie 的价值超过缓存）。因此，AJAX 之前的相同规则适用：
- 用户不应写下密码
- 会话 cookie 应在会话结束时过期
- Web 应用程序需要使用白名单、证书和随机数来确保用户请求的完整性和真实性。
我不能足够强调 XSS 的成功有多少是基于开发人员（包括我自己）的懒惰（或无知）以及用户的困惑和天真。大多数非常大的 XSS 分数都涉及在互联网黑客之前的社交黑客。网络钓鱼诈骗或老朋友或西班牙囚犯的来信，只是要求您关注这个无辜的链接或分享一些无意义的个人信息。在您的银行示例中，我可以看到会使情况变得更糟的一件事是，现在我从该站点知道您的名字是 Alex，并且从 URL 知道您的姓氏是 Forester。这可能会使挖掘细节以使您更容易摆脱其他信息。
所以总而言之，最后：
RESTful 和 AJAX 不会像浏览器历史和糟糕的服务器安全性那样构成更大的威胁，因此同样的规则适用于用户和开发人员。但是你完全正确，这样的 RESTful URL 指出我们在这些实践方面变得更糟，而不是更好；用技术来偷懒，而不是利用优势专注于真正的努力。
那很有趣。回到盐矿。