自增主键不会暴露数据吗?

Question

假如有一个get请求的接口，传的参数是id = 1这样子的，那么不是可以被用户拿到所有的数据了吗

for (let index = 0; index < 1000000; index++) {
  get(index).then(res => {
    if (res != null) {
      console.log(res)
    } else {
      // 该id的数据为空
    }
  })
}

像这种情况怎么处理呀

如果这个情况的话，被别人调用了删除的接口不是很恐怖吗，因为删除接口也是传一个id过去后端就删除了

Answer 1

1 如果数据是公开查看的

那么本来用户就能看到所有这些数据

2 如果数据是非公开的

那么肯定有权限控制用户可以看哪些数据，不能看的知道ID也看不了

自增ID带来的实际问题是：

即便不能看到数据，但是能推测你的业务相关的数据量多少。

Answer 2

自增id我认为最大的麻烦，是给爬虫提供了更方便的方式。。。毕竟可以可以直接从1爬到头。。。
所以即使是开放的数据，我也觉得加上接口的token验证和使用uuid比较好。
至于删除的部分，正常都会有删除方面的控制逻辑，但是如果是一个人，获取了admin权限，那么的确自增id会更加方便的让他快速删除。

Answer 3

最简单的理解方式：
本来有100条数据就是给你看的，你通过id=n可以查看，但是你想删除，就需要你能够登录了，并且确定你有权限才可以。

比如:思否的你这个问答链接是：https://segmentfault.com/q/1010000043448010，其实只要改后面的数字就能看到其他问答，这种数据就是给你看的，即使你能找到规律也没关系，但是你能删除其人的问答吗？

Answer 4

他能知道前后的id，但他没权限删除啊！

你执行删除操作的时候，肯定得判断下这个用户的权限，至少这个id是属于他本人的，或者有更高权限的管理员，才能进行删除。

Answer 5

首先要知道你想干嘛?说说你的需求,权限控制分很多种

我看你是java,可看看这个
https://spring.io/projects/spring-security

后台控制权限,基本就是控制一个请求链接的权限,一般是
用户表 , 角色表 , 权限表 , 用户关联角色表 , 角色关联权限表
请求这个链接前,查下数据看看有么有这个权限就可以了

Answer 6

你这个问题。就是最常见的 水平越权问题
数据的增删改查权限要控制好。
比如有些数据是需要登陆状态的，那么你请求接口还得带上token。token里面对应的数据得和对应的ID有关联关系。

Answer 7

正常来说，自增id最多只能暴漏用户（或者某个事物的数量）的数量级（大约多少）。

后端在做好权限控制的情况下，不符合条件的用户无法通过自增id来获取更多信息或者进行操作。

Answer 8

就是为了防止你说的这种随便传一个id就可以做到数据的删除，才会有各种校验，鉴权，等等一系列操作。

Answer 9

一般完整的系统都会做权限校验,能直接通过id访问到的接口,说明数据不是特别重要,像删除,修改,添加,这些一般都进行权限校验,用户不能直接操作。理论上只能根据id推算出业务数量级。不过如果真的在意这个事,可以把id使用一套可加解密的方案,

• 从数据库取出的数据是原数据,id加密后,传给前端。
• 前端获取的是加密的id,所以通过前端传给后端,后端解密后,再对数据进行处理

Answer 10

是否使用自增主键，自增主键是否存在风险，看项目的性质和安全性要求。

如果安全性要求很高，不论是否存在自增主键，对接口暴露的都不能是自增主键，之前遇到过这样的系统，这样的好处显而易见，不论爬虫，还是安全性，缺点也显而易见，增加开发成本

如果安全性一般，没特别要求可以直接使用自增主键，比如内网的某些网站，权限意味着哪怕能遍历id，也只能遍历有权限看的一部分，能删也是。哪怕真的被爬虫、恶意篡改，至少公司的人都是实名访问的，可以定位到谁做了这些事，事后弥补。

混合使用，如果系统某些表存在敏感问题，可以给这些表单独做处理

没有绝对对的操作，只有适合的操作，要是开发个几十个人用的小网站，各种考虑安全性，投入成本过大，领导觉得你效率太低，产出太少。对外的网站不考虑安全性是非常严重的问题，不过也要根据网站性质考虑用什么安全级别。