内容摘要：垂直越权漏洞，说白了就是“低权限用户干了高权限用户才能干的事”。比如普通员工能删掉CEO的邮件，实习生能改财务的工资单。这类漏洞在Web应用里比水平越权更致命，因为它直接撕破了角色边界。 上周我审计某

垂直越权漏洞，垂直说白了就是越权“低权限用户干了高权限用户才能干的事”。比如普通员工能删掉CEO的漏洞邮件，实习生能改财务的修复工资单。这类漏洞在Web应用里比水平越权更致命，垂直因为它直接撕破了角色边界。越权

上周我审计某电商后台，漏洞发现一个典型场景：订单导出接口只校验了登录态，修复没校验角色。垂直任何注册用户只要把请求里的越权`/admin/export`改成`/user/export`，就能下载全平台订单。漏洞攻击成本低到发指——改一个URL参数就行。修复而修复方案，垂直恰恰不是越权把接口藏起来，而是漏洞把权限判断下沉到每一层。

第一道防线是接口级鉴权。别指望前端隐藏按钮，那只是UI层面的障眼法。后端必须对每个敏感操作校验当前用户的角色和资源归属。Spring Security的`@PreAuthorize("hasRole('ADMIN')")`注解能快速生效，但要注意别只写在Controller层——如果服务层有内部调用，绕过Controller直连Service就危险了。所以更稳妥的做法是：在Service方法上同样加注解，或者用AOP切面统一拦截。

第二道防线是数据级隔离。很多越权发生在“角色对了但资源错了”的场景。比如运营能查看订单，但只能看自己负责的片区。这时光校验角色不够，还得在SQL里强制注入`WHERE owner_id = 当前用户ID`。我见过一个真实案例：某系统用`MyBatis`动态拼接SQL，开发图省事把用户ID直接拼进查询条件，结果参数篡改就能拉取他人数据。修复方式很粗暴——用`@TenantId`注解或MyBatis拦截器自动追加条件，让开发者没机会手滑。

第三道防线是会话和Token的绑定。JWT有个坑：如果把角色信息写进Token，但服务端不校验Token是否被篡改，那攻击者只要解码JWT、把`role`改成`admin`再重新签名（如果密钥泄露），就能直接提权。所以JWT必须配合短期过期和密钥轮换，更保险的做法是——服务端维护一个“会话-角色”映射表，每次请求都查库，而不是轻信Token里的声明。

还有一个容易被忽略的细节：错误处理。当越权请求被拒绝时，别返回详细的堆栈或业务数据，统一返回403+“无权限”即可。否则攻击者能从错误信息里摸清接口结构，为下一次攻击铺路。这点我在某银行系统渗透测试时深有体会——他们的接口返回了完整的SQL报错，直接把表名和字段名都暴露了。

最后说个反直觉的事：有些团队用“接口白名单”来防越权，但效果很差。因为白名单维护成本高，新接口漏加就成筛子。我更推荐“默认拒绝+显式授权”模式——所有接口默认无权限，只有通过注解或配置显式声明“哪些角色能访问”，才放行。这样即使开发忘了加鉴权，接口也默认是关着的。

修复垂直越权，本质是“信任最小化”的工程实践。别信前端传的角色，别信Token里的声明，别信“内部调用就安全”的假设。每层都校验，每次请求都问一句：“凭什么是你？”——做到这点，漏洞基本就堵死了。