asp.net core 关于自增长ID数据保护（IDOR漏洞）

开始前先大概的描述下IDOR漏洞是啥。嗯！ 举个例子，有一个角色下面有N个用户，拥有这个角色的用户都有自身创建的普通用户操作权限（比如删除）。我们一般情况都是通过表主键来操作这条记录的，那么这么一个功能就涉及到两个接口（查询列表，删除指定用户）。

嗯！查询列表的接口自然是要带着用户对应的主键的（通过删除接口传入ID），聪明的人应该想到了；此时ID是明文的并且主键我们一般都是自增长的，此时就会出现我们可以通过猜测这个参数进行恶意删除。嗯！此时有些人可能会想（也是几种解决方式）：

我可以通过对参数进行加密签名来处理。嗯！但是似乎不是很适合前端，因为JS啥的都给人家了，还谈啥密钥和加密方式。
JS处理不行，我服务端来进行数据操作验证总可以吧。嗯！确实可以。前台传入ID后台在一系列操作前进行身份信息条件筛选。（delete TableName where userID ={ID} and create_Id={login_userID}）就是这么个意思。每次带着这么信息是不是哪里不好，万一团队开发有人忘记了叻，那就很有意思了（我们的用户数据随便你删，开心就好。。。）。这方法挺不错的，就是有点蛋疼。
制造这个问题的原因不就是因为ID是数字自增长吗，我只要让主键无规律不就行了，比如时间戳加随机数，再比如GUID。猜？你慢慢猜去吧。但是这里面涉及到一个小问题，性能和存储空间的问题。（自增长主键和GUID查询性能和占用空间比较）
正如三解决方案，我只要让抛到前台的主键是无规律的并且不可轻松枚举出来好像就可以了.此处是对称加密（百度