OWASP 网站建议这样做：
因此，如果用户无权访问所请求的资源，那么混淆直接对象引用如何提高安全性？
考虑到例如 ASP.NET MVC 站点会增加的复杂性，除了银行站点之外，这是否值得为其他任何东西带来额外的麻烦？
我将通过一个例子来解释这一点：
建议您在数据库中有一个对象列表，名称为：
您有一个查询填充了存储在会话中的哈希表，该哈希表将您有权拥有的水果映射到一个数字：
您无权访问 Orange。然后，您有一个函数允许您将水果添加到篮子中，因此您选择数字 1 或 2（这是间接对象引用）。橙色在此会话中不可访问，因为它不存在于哈希表中（没有数字 3）。使用直接对象引用，您将拥有一个仅使用 Apple、Pear、Orange 而不是数字的函数。因此，您也可以滥用该功能（如果未使用访问控制）将橙色添加到您的购物篮中。
如果有足够的访问控制，我个人认为直接对象引用没有问题。这些访问控制应该进行广泛的测试。可能有比其他应用程序更重要的应用程序可能需要这样做，但想象一下应用程序有成千上万的用户，每 100 或 1.000 个选项对他们来说是唯一的。将所有这些存储在会话中可能会对性能产生重大影响（考虑到服务器需要将每个客户端的这些信息存储在网络服务器上）。
现在回答你的第一个问题：仅仅因为它不会被加载到会话中。在我的哈希表示例中，您根本没有可用的橙色。
我认为您将参考对象定义为绝对对象并与财务相关联。以下情况如何：您是软件供应商，如果您的软件在访问者购买后在线销售。您不希望只有购买者才能访问您产品的超链接吗？
忘记金融（银行网站）甚至软件，比如社交网络。“回到过去”，如果你嗅到了电线，这是一个众所周知的事实，你可以从 tcp 捕获中提取 URI，在浏览器中打开它，你可以立即访问电子邮件、社交网络组件等。
有很多不同的场景你需要它。想一想它是什么：“不安全的直接对象”一个直接可访问的对象，无论出于何种原因都无法保护。我们需要通过为它分配一个“引用”来保护它，这样它就永远不能被“直接命名”。