在URL中公开DB内部ID是不好的做法吗？

例如，假设我有一个users表，每行有一些ID（主键）。暴露URL myapp.com/accountInfo.html?userId=5 ，其中5是实际主键，被视为“坏事”，为什么？

还假设我们正确防御SQL注入。

我最感兴趣的是与Java Web技术堆栈相关的答案（因此是java标签），但一般的答案也会非常有用。

谢谢。

这取决于您解析URL的方式。如果你允许盲目的SQL注入是不好的。您只需要validation用户输入的id。

Stackexchange还会将行的id放入URL中，如地址栏中所示。诀窍是解析部分并获得所有可能的SQL。简单的方法是检查id是否为数字。

在URL中传递并不是坏事，因为它对最终用户没有多大意义 – 如果您在运行应用程序时依赖该值，那么它就是唯一的错误。例如，您不希望用户注意到userId = 5并将其更改为userID = 10以显示另一个人的帐户。

将此信息存储在服务器上的会话中会更安全。例如，当用户登录时，其userID值存储在服务器上的会话中，并且每当查询数据库时都使用此值。如果你这样做，通常不需要通过URL中的userID，但是它不会受到伤害，因为它不会被你的DB查询代码使用。

是的，这是件坏事。您正在公开实现细节。多么糟糕？那要看。它会强制您对用户输入进行不必要的检查。如果其他应用程序依赖于它，则您不再可以自由更改数据库方案。

在URL中使用数据库ID是好的，因为这个ID永远不会在对象（db行）生命中发生变化。因此，URL是持久的 – 这是URL最重要的方面。另请参见Cool URI不会更改。

PK适用于系统。
对用户而言，它可能代表不同的含义：
例如，让我们考虑以下链接。使用主键，它会在产品下显示一个项目
productA，productB，productC;

（A） http://blahblahsite.com/browse/productA/111 （pkey）
（B） http://blahblahsite.com/browse/productB/112 (pkey）
（C） http://blahblahsite.com/browse/productC/113 （pkey）
链接B上的用户可能会觉得ProductB下有112个项目，这是误导性的。

此外，它会在合并表时导致问题，因为PK将自动递增。