用 Hashids 优雅解决 C 端自增 ID 暴露问题

   在 C 端系统中，直接对外暴露数据库自增 ID 往往会带来数据枚举、越权访问等安全隐患。本文将从实际业务场景出发，分析自增 ID 暴露的问题本质，并介绍一种基于 Hashids 的可逆 ID 混淆方案。通过 Hashids，我们可以在不改变数据库结构的前提下，实现对外 ID 的安全化与美观化，兼顾安全性、性能与工程可落地性。
本文主要内容：

• 为什么 C 端系统不能直接暴露自增 ID
  
• 解决方案是什么
  
• hashids有那些功能
  
• hashids的代码实现是什么
  

为什么 C 端系统不能直接暴露自增 ID？

在后端系统中，我们习惯使用数据库自增 ID，并习惯性的直接返回给C端交互使用，例如：

登录接口在登录成功后返回的用户基础信息
{
    "userId": 100,
    "username": "tom",
    "gender": 1,
    "birthday": "2000-10-12 00:00:00"
}
URL上直接有自增ID：GET /api/user/100

可被枚举

只要有人发现这是自增 ID，例如：GET /api/user/100，自然可以被枚举

/api/user/101
/api/user/102
/api/user/103
......

发现了问题没：

• 可以轻松遍历接口、爬虫可以批量扫库
  
• 哪怕你有登录态、鉴权，只要 权限校验有一个点没兜住，后果极其严重：表数据被批量抓取，隐私数据被遍历、爬光
  
• 这类攻击成本极低，甚至不算“攻击”
  

越权

越权的风险被无限放大，你“以为”你做了鉴权，其实不一定，现实情况往往是：

• 接口 A 做了用户校验
  
• 接口 B 忘了
  
• 新接口临时加的，校验漏了
  
• 某个内部接口被误暴露
  

一旦 ID 是可预测的：

• 攻击者只需要找到 一个没校验的入口
  
• 就可以“横向移动”访问所有数据
  

例如，URL中存在自增ID，在C端非常典型的场景是用户分享链接给朋友，如果朋友修改URL中的ID，就会跳转到本不属于自己能看到的数据内容。
业务信息全暴露

通过 ID 就能看穿你的业务信息，例如：
<ul><li data-start="704" data-end="720">

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

这个好，看起来很实用

过来提前占个楼

懂技术并乐意极积无私分享的人越来越少。珍惜

谢谢楼主提供！

不错，里面软件多更新就更好了

谢谢分享，试用一下

感谢发布原创作品，程序园因你更精彩

这个有用。

懂技术并乐意极积无私分享的人越来越少。珍惜

yyds。多谢分享