【发布时间】：2012-07-20 10:22:50
【问题描述】：
如果您将 api 调用绑定到对象的 id，是否可以简单地强制此 api 获取所有对象？如果您想到 MySQL，那么使用增量整数 id 完全可以做到这一点。但是MongoDB呢？ id可以猜吗？例如，如果你知道一个 id，是否容易猜到其他（下一个、上一个）id？
谢谢！
【问题讨论】：
【发布时间】：2012-07-20 10:22:50
【问题描述】：
2019 年 1 月更新： 如 cmets 所述，以下信息在 version 3.2 之前都是正确的。版本 3.4+ changed the spec 以便将机器 ID 和进程 ID 合并为一个随机的 5 字节值。这可能会使找出文档的来源变得更加困难，但它也简化了生成过程并降低了冲突的可能性。
原答案：
+1 对于塞尔吉奥的回答，就回答是否可以猜到而言，它们不是散列，它们是可预测的，因此只要有足够的时间，它们就可以“强制”。可能性取决于 ObjectID 的生成方式以及您如何猜测。为了解释，首先，请阅读此处的规范：
然后让我们逐个分解：
- 时间戳 - 完全可以预测，只要您大致了解数据的生成时间
- 机器 - 这是几个选项之一的 MD5 哈希，其中一些选项比其他选项更容易确定，但高度依赖于环境
- PID - 再次强调，这里的值不是很多，并且可以针对从已知来源生成的数据进行侦查
- 增量 - 如果这是一个随机数而不是增量（两者都允许），那么它的可预测性较差
稍微扩展一下来源。 ObjectID 可以通过以下方式生成：
- MongoDB 本身（但可以迁移、移动、更新）
- 驱动程序（在任何插入或更新数据的机器上）
- 您的应用程序（如果您愿意，可以手动插入自己的 ObjectID）
因此，您可以采取一些措施来让它们更难单独猜测，但如果没有大量的深思熟虑和保护措施，对于正常的数据集，有效 ObjectID 的范围应该很容易计算出来，因为它们都是以时间戳为前缀（除非您以某种方式对其进行操作）。
【讨论】：
-
根据文档，在 Mongo 3.4 及以上版本中，ObjectID 是 12 字节的值，包括：
a 4-byte value representing the seconds since the Unix epoch、a 5-byte random value、a 3-byte counter, starting with a random value. -
@Piotr - 6.5 年后情况会发生变化 :) 我在顶部添加了一条注释，其中包含根据您的注释更新的信息 - 谢谢。
Mongo 的 ObjectId 绝不是为了防止暴力攻击（或任何攻击，就此而言）。它们只是提供全球独特性。您应该不假设某个对象不能被用户访问，因为该用户不应该知道它的 ID。
为了实际保护您的资源，请使用其他技术。
如果您防御未经授权的访问，请在您的应用中放置一些授权逻辑（允许合法用户访问，拒绝其他所有人访问）。
如果您想阻止转储所有对象，请使用某种速率限制。如果适用，请结合授权。
【讨论】：