我听说有些人说你不应该把你的内部ID暴露给外面的世界（例如auto_increment'ng主键）。
有人建议您使用某种uuid列来代替查找。
我想知道为什么会这样建议，如果它真的很重要。
使用uuid基本上只是混淆了id。重点是什么？我唯一能想到的是auto_incrementing整数显然指出了我的db对象的顺序。如果外部用户知道一件事是在另一件事之前/之后创建的，那有关吗？
或者纯粹是混淆id会阻止对特定对象的不同操作进行“猜测”？
在设计面向外部的API时，这是否是我应该考虑的问题？
答案 0 :(得分：5)
很棒的答案，我还要说明为什么您不希望公开内部自动递增ID的其他原因。
答案 1 :(得分：4)
您向恶意用户提供的有关您的应用程序及其布局的任何信息都可以用于您的应用程序。我们在（网络）应用程序安全性方面遇到的一个问题是，当项目规模扩大时，在项目的初期阶段看似无害的设计决策将成为关键。让攻击者对实体的排序做出明智的猜测可能会以下面的，有点无关的方式来困扰你：
实体的ID将不可避免地作为参数传递到应用程序中的某个点。这将导致黑客最终能够提供他们通常无法访问的应用程序参数。我个人能够查看订单详情（在一个非常受欢迎的零售商的网站上），我没有业务查看，作为URL参数不少。我只是从我自己的合法订单中提供应用顺序号码。
了解主键字段值的限制或至少进展是SQL注入攻击的宝贵资料，我在此无法涵盖其范围。
键值不仅用于RDBMS系统，还用于其他键值映射系统。想象一下，如果JSESSION_ID cookie命令可以预先确定或猜到？每个反对大拇指的人都会在网络应用中重播会议。
还有更多，我相信其他人会在这里提出。
海豹突击队6并不一定意味着有6支海豹队。只是让敌人猜测。而且，潜在攻击者猜测的时间在你的口袋里有更多的钱，无论你怎么做。答案 2 :(得分：3)
与许多与安全相关的问题一样，这是一个微妙的答案 - kolossus提供了一个很好的概述。
有助于了解攻击者如何破坏您的API，以及发生了多少安全漏洞。
大多数安全漏洞都是由漏洞或疏忽引起的，攻击者会寻找这些漏洞。试图破坏您的API的攻击者将首先尝试收集有关它的信息 - 因为它是一个API，可能是您发布了详细的使用文档。攻击者将使用此文档，并尝试许多不同的方法来使您的网站崩溃（从而暴露更多信息，如果他很幸运），或以您未预料到的方式做出反应。
你必须假设攻击者有很多时间，并且会编写攻击脚本来尝试每一条大道 - 就像一个无限时间的窃贼，在你的房子周围试着每一个门窗，用一个锁定选择来学习每一次尝试。
因此，如果您的API公开了getUserInfo(userid)之类的方法，并且userID是一个整数，则攻击者会编写一个脚本，从0向上迭代，找出您拥有的用户数。他们会尝试使用负数，max(INT) + 1。您的应用程序可能会在所有这些情况下泄漏信息，并且 - 如果开发人员忘记处理某些错误 - 可能会泄露超出您预期的数据。
如果您的API包含限制访问某些数据的逻辑 - 例如您被允许为您朋友列表中的用户执行getUserInfo - 由于错误或疏忽，攻击者可能因某些号码而幸运，并且他知道他所获得的信息与之相关对于有效的用户，他们可以建立应用程序设计方式的模型。它相当于一个窃贼知道你所有的锁都来自一个制造商，所以他们只需要带上那个锁扣。
就其本身而言，这可能对攻击者没有任何好处 - 但它使他们的生活更容易一些。
考虑到使用UUID或其他无意义标识符的努力，它可能值得为攻击者制造更难的东西。当然，这不是最重要的考虑因素 - 它可能不会使你应该做的前5件事来保护你的API免受攻击者的侵害 - 但它有所帮助。