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

问题描述

在我的职业生涯中，我有过几次这样的讨论.在我看来，在 REST API 响应中将存储在数据库中的 id 公开给客户端是完全可以的.但是，与我共事过的一些人认为，这确实是安全方面的第一课:永远不要将您的数据库 ID 暴露给客户端."

I have had this discussion a couple of times in my career. In my view it is perfectly okay to expose the ids that are stored in the database to the client in your REST API response. But some people I've worked with think this is really one of the first lesson in security: "Never expose your database IDs to the client."

然后它们会带来各种复杂性来避免这种情况.例如，在一项工作中，我必须对其余响应中的每个 ID 进行散列，然后对请求中的所有 ID 进行散列.

Then they come with all kind of complexity to avoid this. For example, in one job I had to hash every ID in my rest response, and then unhash all the ids in the request.

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

Now in my new job we have the following pattern. A table has an auto incrementing "id", but we don't expose that, next to that we have a uuid "code", and that is the one we expose to the client. So essentially we have 2 ids, both stored in the DB, but one we can expose, the other we can, because:

永远不要向客户端公开您的数据库 ID."

"Never expose your database IDs to the client."

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

Does this even slightly make sense? We still expose an "identifier" to the client. If the problem is that someone can see how many rows we have in a table, because that "id" is auto incrementing, I would just make the "id" an uuid, and expose that to the client.

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

If you look at examples of other public rest API's, it always seem to me that they expose the database id, without problem. For example, 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}

But even stackoverflow:https://stackoverflow.com/questions/{id}https://stackoverflow.com/users/{id}

我敢打赌，url https://stackoverflow.com/users/2188707 中的 2188707 只是我在 stackoverflow 数据库中的用户 ID.

I would bet that 2188707 in the url https://stackoverflow.com/users/2188707 is just my user id in the stackoverflow database.

推荐答案

我认为在您的 API 中公开普通数据库 ID 没有任何安全原因.如果您的数据库暴露了，您无论如何都丢失了.通过默默无闻来确保安全永远不是解决方案.

I don't see any security reasons to expose the plain database ID in your API.If your database is exposed you have lost anyways. Security through obscurity is never a solution.

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

However, there are some other reasons to consider:

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

• Exposing the database ID creates a coupling to your database. Imagine merging data from different databases (sharing the same schema), or applying backup data to an already in use database. There will be no guarantee that the same ID's will still be available.

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

Designing a proper Resource based API requires you to expose universally unique ids (UUID) or a technical composite key for the simple reason that there is no other way to ensure uniqueness across different systems/databases.

这篇关于在 REST API 中向客户端公开数据库 ID 是一种不好的做法吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！