越权漏洞的渗透修复，从来不是测试加个if判断那么简单。上周我帮朋友排查一个电商后台，越权订单详情接口明明校验了用户身份，修改但换个订单号就能看到别人的渗透收货地址。问题出在哪？测试开发者把用户ID放在了请求参数里，后端只校验了“登录状态”，越权压根没校验“订单归属”。修改

这类漏洞分两种：水平越权是渗透平级用户互看数据，垂直越权是测试普通用户干管理员的事。修法完全不同，越权别混为一谈。修改水平越权核心是渗透“数据归属校验”，垂直越权核心是测试“角色权限校验”。

先说水平越权。越权最直接的修改方式，是后端强制从Session或Token里取用户标识，而不是信任前端传的user_id。比如Java里用`session.getAttribute("userId")`，PHP用`$_SESSION['uid']`。前端传的参数一律当攻击数据对待——哪怕它看起来再正常。

但光改参数来源还不够。我见过一个系统，用户ID确实从Session取了，但查询订单时只用了`WHERE order_id = ?`，没带用户条件。攻击者遍历订单号照样泄露数据。正确写法是`WHERE order_id = ? AND user_id = ?`，把归属条件写进SQL里。这招对绝大多数水平越权都有效。

垂直越权要麻烦点。很多系统只在菜单层面隐藏了管理员按钮，但后端接口没做角色拦截。我前公司就出过事：普通员工直接POST请求`/admin/deleteUser`，服务器居然响应200。修这个得用框架的权限中间件，比如Spring Security的`@PreAuthorize("hasRole('ADMIN')")`，或者ThinkPHP的路由分组权限配置。别自己写if判断角色，容易漏。

还有个细节特容易被忽略——越权修改往往藏在批量操作里。比如“批量导出”功能，前端只传了勾选的ID列表，后端如果没逐条校验归属，一次就能拖走全库数据。修这种问题，循环里每条数据都得过一遍权限校验，别图省事只校验第一条。

最坑的是那些看似“安全”的写法。有人用UUID代替自增ID，觉得攻击者猜不到。天真了。UUID可能出现在日志、前端源码、分享链接里，只要泄露一个，水平越权照样玩得转。真正的安全是每个请求都做归属校验，而不是靠ID不可预测。

改完代码记得测边界情况。比如订单属于已注销用户怎么办？子账号继承了主账号权限怎么处理？我习惯写测试用例时专门构造“A用户登录，操作B用户资源”的场景，跑一遍自动化测试。手点也行，但容易漏掉深层嵌套的资源——比如先查项目，再查项目下的任务，任务里的附件——每一层都要校验。

最后说句实在话：越权修改没有银弹。哪怕你用Spring Security、用了Shiro，业务逻辑里的数据范围过滤还是得自己写。别迷信框架，多看看别人是怎么被黑的，比背一百个修复模板都管用。