去年一家做SaaS的越权客户找我做渗透测试。他们的漏洞系统有个功能：普通用户能查看自己团队的账单明细。我登录后把URL里的解决team_id从1024改成1025，页面刷新，越权另一家公司的漏洞账单全出来了。金额、解决发票号、越权付款方式，漏洞一清二楚。解决这就是越权纵向越权——用低权限的身份，干了高权限的漏洞事。

纵向越权和横向越权经常被混着说，解决但两者不一样。越权横向是漏洞平级串门，A用户看B用户的解决数据；纵向是向上爬，普通用户摸到了管理员的功能。危害更大，因为管理员接口往往能批量操作、修改配置、甚至执行系统命令。很多开发者的注意力放在“用户有没有登录”上，却忘了问“这个用户有没有资格调这个接口”。

问题出在哪？我翻过不少代码，最常见的写法是：接口只校验了token有效性，没校验角色。比如一个删除用户的API，前端可能藏了入口，普通用户看不到按钮，但后端压根没做角色判断。攻击者抓包拿到接口地址，直接发请求，服务器照单全收。前端隐藏不等于后端授权，这个道理说了很多年，还是有人踩坑。

还有一种更隐蔽的情况：接口做了角色校验，但校验逻辑写错了。比如用角色ID比较大小，认为role_id大于等于2就是管理员。结果某个业务角色ID刚好是3，普通运营人员就能调管理员接口。这种逻辑漏洞靠工具扫不出来，得人工看代码或者做细致的权限矩阵测试。

怎么解决？核心就一句话：每个请求都要在后端重新确认“你是谁”和“你能不能”。别信前端传来的任何角色标识，别信URL里的权限参数。用户身份从session或token里解，权限从服务端数据库或缓存里查。每一次敏感操作，都走一遍完整的鉴权链。

具体落地时，我习惯建议团队做三件事。第一，把所有接口按角色画一张权限表，谁可以调、谁不可以，写清楚。第二，在框架层面加一个统一的鉴权拦截器，别让每个开发自己写if-else。第三，针对纵向越权做专项测试用例，用低权限账号遍历所有高权限接口，看返回码是不是403。返回200就是漏洞。

有个细节值得提：有些系统用UUID做资源标识，觉得猜不到就安全了。但纵向越权不靠猜ID，靠的是直接访问功能接口。UUID挡不住越权，它只是让横向越权变难一点。真正的防线是服务端的权限判断，跟ID长什么样没关系。

另外，微服务架构下这个问题更容易失控。网关层做了鉴权，内部服务就默认请求可信。结果某个内部接口被暴露到公网，或者某个服务被攻破后横向移动，权限体系直接崩塌。零信任的思路在这里适用：每个服务都要独立鉴权，别把网关当唯一门神。

我见过修复得最干净的团队，是把权限模型从RBAC升级到了ABAC。不光看角色，还看资源归属、操作时间、请求来源IP。普通用户即使拿到了管理员接口地址，属性不满足照样拒绝。代价是复杂度上去了，但核心业务值得这么做。

说到底，纵向越权不是技术难题，是意识问题。开发者总觉得“用户不会那么干”，攻击者偏偏就那么干。把每个接口都当成公开接口来设计鉴权，漏洞自然就少了。