我注意到SO和其他网站使用用户表的自动递增主键作为可公开查看的用户ID（至少我认为这是他们正在做的事情）。在SO的情况下，如果您知道或可以猜测其用户ID，则可以查看用户的个人资料。
在实现类似的用户ID生成方式之前需要考虑哪些事项？我正在开发一个非商业应用程序，它依赖于“朋友”的概念在用户之间分配各种权限，但我希望所有用户的基本配置文件都可以在一个简单的URL上查看，例如app.com/users/userid。更详细的个人资料信息只能由该用户确认的该用户的“朋友”访问。
我想我的问题是，用户ID的“可猜测性”是否表明了像这样的系统的固有安全性，或者是否真的实现了各个功能？有什么我可能不会考虑这个会使它变得不明智吗？我绝对应该避免使用这些用户ID吗？
注意事项我根据最近用户的数量或用户之间的变化率，不关心“竞争对手”知道或猜测我拥有多少用户。
答案 0 :(得分：2)
OWASP - Insecure Direct Object References
对这个问题给予了很好的对待。事实上，在开发Web应用程序时，我强烈建议使用OWASP作为安全指南。我总是根据网站上发现的十大安全威胁评估我的网络项目。
答案 1 :(得分：1)
这根本不是问题。事实上，我几乎反过来说：如果你为了安全而不得不掩盖URL中的params，那么你做错了;应该在代码中处理安全性。
从您的问题来看，您似乎已经以正确的方式考虑安全问题，因此您可以使用网址中的主键。
拥有一个不存储任何信息的primary_key（比如auto_incremented id）也很好，因为它永远不会改变。如果您在URL中输入用户名等信息，您可能希望永远不会实现能够编辑其用户名的人员，或者应对可能会丢失的链接（请记住，这些链接可能位于您的网站之外） ）。
在您的网址中具有auto_incremented id的唯一信息可能是泄漏，即一个用户将知道他们是在另一个之前或之后的用户。这不太可能是一个问题（无论如何可能都不可靠）。