去年冬天，权限绕过一个做安全测试的权限绕过朋友给我看了张截图。某政务App的权限绕过登录接口，他把请求里的权限绕过user_id从自己的改成隔壁老王，服务器居然把老王的权限绕过身份证号、社保记录全吐了回来。权限绕过没有二次验证，权限绕过没有token校验，权限绕过就一个数字的权限绕过差别。

这就是权限绕过权限绕过。说白了，权限绕过系统该拦你的权限绕过地方没拦，你本该只能看自己家窗户，权限绕过结果推开了整栋楼的权限绕过门。

它不总是权限绕过"黑客"干的

很多人觉得权限绕过离自己很远，那是搞渗透的人才碰的东西。但实际情况是，大部分权限漏洞是开发阶段自己埋的。

我见过一个后台管理系统，前端把"删除用户"按钮藏起来了，普通管理员看不到。但接口地址就写在JS文件里，/api/user/delete?id=123，任何人拿浏览器F12看一眼就能找到。点不了按钮？直接敲URL就行。前端隐藏不等于后端拦截，这个道理讲了八百遍，还是有人只做表面功夫。

还有一类更隐蔽的。某SaaS平台用JWT做鉴权，token里塞了role: "user"。问题在于签名密钥用的是默认值secret。攻击者自己签一个role: "admin"的token，服务端照样认。这不是绕过，这是门锁装了但钥匙插在锁上没拔。

水平越权和垂直越权，两码事

水平越权是同级之间的。你是用户A，你能看到用户B的数据。刚才说的改user_id就是典型。这类漏洞在订单查询、消息读取、文件下载这些场景里特别常见。因为开发的时候往往只验证了"你登录了没有"，没验证"你登录的是不是这个资源的拥有者"。

垂直越权是低权限干了高权限的事。普通用户执行了管理员操作。比如一个论坛，普通用户通过修改请求方法，把GET /api/posts改成DELETE /api/posts/1，如果后端没做角色校验，帖子就没了。

两种越权的根因一样：信任了不该信任的输入。但修复思路不同。水平越权要在每次数据访问时带上当前用户身份做过滤，垂直越权要在每个敏感操作前检查角色权限。没有捷径。

一个真实案例的细节

2023年某在线教育平台被曝出漏洞。学生登录后，课程视频的播放地址是/video/play?course_id=1001&uid=500。有人把uid改成501，发现能看别人的付费课程。改成1，看到了平台创始人的管理后台入口。再往上，数据库连接字符串都在返回的JSON里。

问题出在哪？后端拿到uid参数后直接拿去查数据库，没有和当前会话里的用户ID做比对。一个参数，三层越权，从看盗版课到拖库，就差几步。

这个案例让我印象深的原因是：漏洞利用链太顺了。顺到不像"攻击"，像正常操作。很多权限绕过的可怕之处就在这——它不需要多高深的技术，只需要你多改一个数字，多试一个接口。

怎么防

说几个实际管用的做法。

所有涉及资源ID的接口，后端必须从session或token里取当前用户ID，拿这个ID去查数据，而不是信任前端传来的任何用户标识。这条如果做到位，能挡住八成以上的水平越权。

敏感操作走统一的权限中间件。别在每个接口里手写if role == "admin"，写多了总会漏。集中管理，集中校验。

还有一点容易被忽略：日志和监控。权限绕过往往伴随异常的ID遍历行为。如果同一个账号在短时间内请求了大量不同用户的资源ID，这事就该报警了。很多系统被刷了几万条数据才发现，就是因为没有这层监控。

权限绕过不是什么高深的安全课题。它更像是开发过程中一个偷懒的瞬间——觉得"应该没人会改这个参数吧"。但互联网上，永远有人在改参数。你没想到的地方，就是别人进去的门。