我非常喜欢MongoDB自动生成的ID。它们非常有用。
但是，是否可以公开使用它们？
假设有一个帖子集合，以及带有id paramater的/ posts页面（类似于/ posts / 4d901acd8df94c1fe600009b）并显示有关它的信息。
这样，用户/黑客就会知道文档的真实对象ID。它没关系还是不安全？
由于
答案 0 :(得分：34)
ObjectID documentation表示自动生成的ID包括3字节的机器ID（可能是MAC地址的散列）。通过比较各种ID中的这三个字节，有人可以弄清楚你的内部网络的事情，这是不可想象的，但除非你为五角大楼工作，这似乎并不值得担心（你更容易受到攻击）像配置错误的Apache更无聊的事情。）
除此之外，Epcylon的权利;通过URL公开id没有任何内在的不安全因素。当然，它是否是<丑> 是另一回事。你可以使用它们来缩短它们（我自己一直在考虑这个问题），但是有一个奇怪的事实是它们都差不多一半。
答案 1 :(得分：7)
我没有在生产环境中使用MongoDB的经验，所以不要把我的答案当作事实，但我无法想象它为什么不安全。
与RDBMS中的Auto-ID类型列进行比较。你总是将它们暴露在外面，我不知道有什么理由不对MongoDB id做同样的事情。
与往常一样，安全性应该是验证您的输入，而不是让没有适当保护的数据库附近的任何人。做得恰当，如果他们知道如何选择数据库中的特定对象，则无关紧要，因为他们仍然无法对其进行任何操作。
答案 2 :(得分：7)
我认为mongodb _id基于日期戳，服务器地址以及您可能希望保密的其他内容。
如果您担心可能需要加密mongoids并将结果用作客户端标识符（然后在请求返回时取消加密）。
如果加密密钥部分基于相关用户或会话的某些唯一属性，那么用户很难在不应该访问内容时访问内容。
通过其他方式验证用户显然仍然很重要！
答案 3 :(得分：4)
或许将此视为隐私而不是安全性问题。
我面临着同样的问题。在基于Mongo生成的ID将用户贡献的内容存储在Web可访问的目录中时，如果这些ID可预测一个用户可以访问另一个用户的内容，则存在风险。
我认为其他人的建议是正确的路线：了解用户特定私有内容的网址不应该足以访问。尝试访问时应检查匹配的用户是否正在发出请求。
我打算在Symfony2中通过存储Web根目录的外部来实现此目的，然后允许通过新路由/ Controller访问它，在传递响应之前将验证一些识别信息。用户。
答案 4 :(得分：2)
使用MySql中的自动增量id值不再是不安全的。这不是任何安全漏洞。
答案 5 :(得分：2)
如果id指向仅包含链接的“不公开”内容的链接 - 这是隐私问题。
如果id提供了指向用户登录内容的链接 - 不是问题。
无论是MongoDb，SQL还是其他任何ID。 Id是数据的关键。如果这个键只是你需要查看你不应该看的内容 - 这是一个问题。对于这种情况 - 生成无法识别的id。
答案 6 :(得分：1)
从版本MongoDB 3.4开始，MongoDB不再包含机器标识符，如标记的答案。但是id仍包含一个timestamp，可用于查找何时创建数据。如果您不希望 ID 存储与人们可以用来映射数据的数据相关的任何信息，则可以按照我的操作进行操作。
我在生产阶段就使用过MongoDB。通常，在我的系统上，所有MongoDB文档都具有2个唯一的ID。
第一：默认MongoDB _id（由MongoDB自动生成）
_id（默认）我使用此ID在内部系统中进行查询。例如用于collection，缓存等之间的关系的示例。使用ObjectId进行查询比查询其他数据类型（例如string）要快得多。 / p>
第二：公共ID（由您的应用生成）
pubId-您可以用任何东西替换它。 （请务必使用简洁明了的名称）UUID 快 40％）A-Za-z0-9_-）当客户端应用导出并使用数据时，我将其用作主要ID。例如 APIs 之间的数据输入和退出，与第三方应用程序的集成，作为表中行的 id元素客户应用程序等。
答案 7 :(得分：0)
说我们有 由用户a订购1 由用户b订购2
为两个用户公开顺序1或2的docid是安全的（尽管您的代码应公开a的1和b的2）
但是重要的是验证
如果只允许用户阅读并且您有/ api / modifyorder /：docid之类的信息 您必须验证用户是管理员
如果用户B拥有订单1（用户A）的docid，则需要在提供响应之前检查订单用户ID（如果尝试这样做，则记录安全日志）