rest - 在 REST API 中向客户端公开数据库 ID 是一种不好的做法吗？

Question

在我的职业生涯中，我曾多次讨论过这个问题。在我看来，在您的 REST API 响应中将存储在数据库中的 id 公开给客户端是完全可以的。但与我共事过的一些人认为这确实是安全性的第一课:“永远不要将你的数据库 ID 暴露给客户端。”

然后它们会带来各种复杂性来避免这种情况。例如，在一项工作中，我必须对我的休息响应中的每个 ID 进行哈希处理，然后对请求中的所有 ID 进行取消哈希处理。

现在在我的新工作中，我们有以下模式。一个表有一个自动递增的“id”，但我们不公开它，在它旁边我们有一个 uuid“代码”，这就是我们向客户端公开的那个。所以本质上我们有 2 个 id，都存储在数据库中，但一个我们可以公开，另一个我们可以，因为:

“永远不要将你的数据库 ID 暴露给客户端。”

这甚至有点道理吗？我们仍然向客户端公开一个“标识符”。如果问题是有人可以看到我们在一个表中有多少行，因为那个“id”是自动递增的，我只会让“id”成为一个 uuid，并将其公开给客户端。

如果您查看其他公共(public)休息 API 的示例，在我看来，它们总是公开数据库 ID，没有问题。例如，gitlab:

GET /projects/:id/users

[
  {
    "id": 1,
    "username": "john_smith",
    "name": "John Smith",
    "state": "active",
    "avatar_url": "http://localhost:3000/uploads/user/avatar/1/cd8.jpeg",
    "web_url": "http://localhost:3000/john_smith"
  },
  {
    "id": 2,
    "username": "jack_smith",
    "name": "Jack Smith",
    "state": "blocked",
    "avatar_url": "http://gravatar.com/../e32131cd8.jpeg",
    "web_url": "http://localhost:3000/jack_smith"
  }
]

推特: https://api.twitter.com/1.1/statuses/show.json?id={id}
但即使是stackoverflow: https://stackoverflow.com/questions/{id} https://stackoverflow.com/users/{id}
我敢打赌 2188707在网址中 https://stackoverflow.com/users/2188707只是我在 stackoverflow 数据库中的用户 ID。

Answer 1

我没有看到任何安全原因在您的 API 中公开纯数据库 ID。
如果您的数据库暴露在外，您无论如何都会丢失。通过默默无闻的安全永远不是解决方案。

但是，还有一些其他原因需要考虑:

公开数据库 ID 会创建与数据库的耦合。想象一下合并来自不同数据库的数据(共享相同的模式)，或者将备份数据应用到已经在使用的数据库中。无法保证相同的 ID 仍然可用。

设计一个适当的基于资源的 API 需要您公开通用唯一 ID (UUID) 或技术复合键，原因很简单，因为没有其他方法可以确保跨不同系统/数据库的唯一性。