假设我们构建了一个为用户提供某种配置文件页面的网页，那么应该通过使用唯一ID来识别每个用户。在MongoDB中，这很可能是文档的_id列。处理用户配置文件的链接时，我觉得在网络链接中公开实际的数据库ID感觉不舒服，例如
https://www.foopage.com/userprofile/5612afeedd2387aeeebbdd211100ccdd
相反，我想介绍一个较短的标识符，也可以在youtube上看到每个视频都有一个唯一的10位字母数字代码。 我现在的问题是：
1）从安全的角度来看：是否值得将公开的实际ID隐藏起来，还是实际上没有增强系统安全性呢？
2）我期望通过使用我自己的标识符来降低性能，因为MongoDB的本地_ID很可能被索引和“优化”，而我的标识符总是需要某种数据映射或附加索引。你有什么经历？使用本机索引和MongoDB手动创建的索引是否有任何记录差异？
答案 0 :(得分：1)
1）从安全的角度来看：是否值得将公开的实际ID隐藏起来，还是实际上没有增强系统安全性呢？
通常攻击者不应该从了解ObjectID中获益。这意味着除非您在应用程序中构建一些可以通过知道ID来利用的安全漏洞。
您需要注意的另一件事是ObjectID并非完全随机。它们还会泄漏机器标识符，生成它的进程的进程ID以及生成ID的日期和时间。有关详细信息，请参阅the documentation。这些信息都不是真正的安全关键（尽管创建时间是您可能不希望在某些案例中显示的内容），但对于试图利用您的某些其他漏洞的攻击者而言，这可能是有价值的信息。系统。
这意味着隐藏ObjectsID作为深度防御策略的一部分可能很有用，但它只是通过默默无闻的安全性。不要指望ObjectID是秘密的。
2）我期望通过使用我自己的标识符来降低性能，因为MongoDB的本地_ID很可能被索引并且优化了＃34;而我的标识符总是需要某种数据映射或附加索引。
您知道您的_id值不需要是ObjectID吗？您可以使用任何类型的任何值，只要它在集合级别上是唯一的。因此，如果您的数据已经具有唯一标识符，则可以将其用作_id并保存一些字节和索引。为此，只需将文档的_id字段设置为所需的值，然后再将其插入数据库。
如果要保留_id:ObjectID模式，只需在特定于应用程序的ID字段上创建唯一索引即可。您现在至少有两个索引在每个插入时都会更新，但是除非您的应用程序非常繁重（在Web应用程序的上下文中这是不常见的），否则对此的性能损失不会非常严重。
顺便说一下：网址example.com/userprofile/5612afeedd2387aeeebbdd211100ccdd对搜索引擎不是很友好。最好使用example.com/userprofile/IgorP这样的网址。它们对搜索引擎和人类用户都更具可读性。