一个OWASP 说明建议直接对象引用在某些情况下被认为是不安全的。他们将“直接对象引用”定义如下：
“当开发人员将对内部实现对象（例如文件、目录、数据库记录或键）的引用公开为 URL 或表单参数时，就会发生直接对象引用。”
有人建议解决这个问题：
对象引用映射首先由临时存储在会话中的授权值列表填充。当用户请求一个字段（例如：color=654321）时，应用程序会从会话中查找此映射以确定适当的列名。如果该有限映射中不存在该值，则用户未被授权。参考地图不应该是全局的（即包括所有可能的值），它们是临时地图/字典，只填充了授权值。
但是，其他人在 Wiki 上争辩说，DOR 仅对文件、目录确实不安全。那个人补充说：
在真正的企业或企业后系统中，实际上没有办法对所有数据库主键进行 DOR。
我的问题是，对数据库主键的直接对象引用有多不安全？你能提供漏洞的具体例子吗？人们多久（如第一人所建议的那样）不遗余力地屏蔽所有数据库键？
问题不在于直接对象引用，而在于不安全的直接对象引用。例如，假设您有一个显示私人消息的脚本，并且该脚本将 ID 作为参数。如果您查看用户的列表，您将看到指向您有权访问的消息的链接。但是，如果您可以在参数中更改该 ID，并使用它来查看任意其他消息，则构成不安全的直接对象引用。
有些人认为创建一种将用户特定 ID 映射到对象的机制更安全，因为它本质上需要您考虑访问控制。
隐藏数据库密钥并不是完全需要的，但如果攻击者试图在攻击中引用内部 ID，它确实会让生活变得更加困难。对文件名和其他此类内部标识符的直接引用可以让攻击者映射服务器的内部结构，这可能在其他攻击中很有用。这也引发了路径注入和目录遍历问题。
向公众公开 ID 时需要担心许多因素。我认为最重要的是避免爬虫。如果我知道/page.php?id=1将显示与数据库中的一条记录相关的信息，那么/page.php?id=2必须按顺序显示下一条记录的信息，并且/page.php?id=3是下一条，依此类推，这样我就可以读取表上的所有信息，可能会访问到东西例如，我不应该喜欢在论坛上受密码保护的部分下发帖。
但是，如果 ID 实际上是使用我不知道的密码加密的，我将无法再轻松地爬取数据库记录，我将不得不从我有权访问的页面中获取 ID，因此我只能访问我自己的信息应该的。
我自己有一个案例，您应该能够看到游戏角色的个人资料，但您不应该自己访问此页面。只有在角色所有者向您提供 URL 时，您才能看到它。此 URL 带有一个加密短语，其中包含加密 ID、CRC 检查以避免暴力破解，甚至是其自身的到期日期。