安全 API 设计：你们是用 UUID 还是 HEX?

xiaoronglv · 2022年08月29日 · 最后由 hooopo 回复于 2022年09月12日 · 1648 次阅读

通常大家设计 Restful API 时，会直接返回资源的数字 id 给前端。比如以下一个关于账单的 API，返回当前绑定的信用卡，它的资源 id 是一个数字。

GET /v1/credit_cards.json

{
  id: 13232,
  number: "61333313333000",
 ...
}

为了安全，大家都会加上过滤条件 where(company_id: current_company.id) 。

CreditCardsController
  def index
    render CreditCard.credit_cards.where(company_id: current_company.id)
  end
end

这样公司 A 的员工就不能访问公司 B 的数据了。但是如果万一有程序员忘记加 where(company_id: current_company.id) 这个 filter，就会导致数据泄露。

我看到有些公司的做法是，返回十六进制的 id。

比如 checkr

https://docs.checkr.com/#operation/getCandidate

第一个问题：为什么大家不在 API 中用 uuid 呢？

创建方法

SecureRandom.uuid

如果用 uuid，黑客更不容易拼出完整 URL。
万一某个 API 有安全漏洞，也不容易导致大规模的数据泄露。

比如 API response 范例


{
  uuid: "6c8aa96e-4293-408c-baf7-01980faec5bc",
  number: "61333313333000",

}

第二个问题：大家在设计企业应用时，返回给前端（合作伙伴）的是 uuid 还是十六进制的 id？

感觉十六进制的 id 还是比较容易猜的。

SecureRandom.hex

第三个问题：大家在做集成时，uuid 和 hex，哪个更常见？

5 个赞

zhongsheng #1 2022年08月29日

我一般情况会用 uuid，有些场景和系统会对 ID 长度有要求没办法用 uuid

1 个赞

xinyifly #2 2022年08月29日

以传统 MySQL 的主键索引习惯为例，数据表在文件中按主键顺序存储，如果使用 UUID 作为主键且采用了无序的设计，会导致新增数据需要重新排列。或者采用自增主键与 UUID 索引键共存的方案，对外暴露 UUID 索引键。

如果想只用一个主键，应该采用能按大小顺序生成序列的键，比如雪花算法

（其它数据库系统或主键索引策略不了解）

2 个赞

hellorails #3 2022年08月30日

pg & uuid

1 个赞

hging #4 2022年08月30日

https://github.com/norman/friendly_id 也挺好的。

2 个赞

xianyuit #5 2022年08月30日

Uuid 太长了不太好看我自己喜欢生成一个 I'd

hellonunam #6 2022年08月31日

还是比较喜欢生成纯数字的

themadeknight #7 2022年09月02日

GraphQL 里的方式是输出的时候可以选择给 ID 加密输出，接收的时候再 restore，我觉得这种方式不错，数据库也可以使用传统的 id

xiaogui #8 2022年09月02日

Hashids?

darkbaby123 #9 2022年09月08日

我现在一般用 UUID，不用数据库自增长 id 了。自增长 id 容易被猜到临近的资源和数据库实际规模。后期改分布式比较麻烦。优点就是简单和短。UUID v4 方便，但在实际使用中通常觉得太长，尤其是 URL 中使用，而且有些人会有 id 按时间排序的要求。这点应该只有 UUID v5 可以做得到，但它本质上需要开发者自己保证唯一性。

现在互联网应用也很少看到自增长 id，而是用各种字符 id。实际项目中对 ID 一般考虑几点：

是否需要前后端都可以生成
是否需要异构的微服务都方便生成
是否需要中心化的 ID 生成服务，还是每个服务可以自己生成（只要遵循统一的算法）

如果考虑 1，那么只能考虑 JS 也能生成的方式，比如 UUID v4 / NanoID / Hashids 都行。如果考虑 2，那么需要一个有多种主流语言实现的方式，或者雪花算法。这个思路其实很值得学习，基本上是分布式 ID 的通用套路了。另外 MongoDB 的 ID 生成方式也可以考虑。

贴一个 Instagram 的分布式 ID 生成思路。能做到 Postgres 里去，保持数据库生成 ID 的同时效率不低。

hooopo #10 2022年09月08日

UUID + MySQL 的话，数据迁移是灾难，虽然数据迁移的概率很低，但估计要比迁移到分布式数据库发生的概率高很多
UUID + InnoDB 索引膨胀，因为 InnoDB 的二级索引是指向主键的，就是多一条二级索引就膨胀一些，当然还有 buffer pool 和磁盘之类一定也膨胀

所以选不选 uuid 是一个技术层面的需求，和你使用具体的 DB 直接相关。而业务相关的需求完全可以通过其他手段解决，比如 https://github.com/namick/obfuscate_id 你完全可以使用 bigint，然后暴露给外部 string，再反向解析回来。退一步讲，真的有分布式需求或者客户端同步需求，从 bigint 往 UUID 迁移也是容易的。

1 个赞

darkbaby123 #11 2022年09月08日

对