某电商平台，平行一个普通用户登录后想修改自己的越权收货地址。他打开抓包工具，漏洞把URL里那个代表用户ID的平行参数从“10001”改成“10002”。服务器没拦他，越权直接返回了用户10002的漏洞地址列表。他试着把保存请求里的平行ID也改掉，竟然把别人的越权默认地址改了。

这不是漏洞什么高深攻击，就是平行平行越权。开发人员写接口时只校验了“你是越权否登录”，却没校验“你操作的漏洞是不是自己的数据”。一个循环遍历ID，平行就能把全站用户的越权隐私拖走。

平行越权漏洞的漏洞本质就一句话：权限验证缺失了归属判断。攻击者A和B处于同一角色，但A可以访问B的数据。这和垂直越权不同——垂直越权是普通用户干管理员的事，平行越权是用户之间互相偷看。

我见过很多代码评审里的低级错误。程序员图省事，在controller层直接拿前端传来的user_id去查库，压根没从session里取当前登录人。还有更隐蔽的——把用户ID放在JWT的payload里，但验签时没校验该ID是否和当前会话一致。这些漏洞在开发自测时通常发现不了，因为测试账号往往只有一个。

真正可怕的是它的连锁反应。单个平行越权可能只是泄露一条订单记录，但如果接口支持批量查询，比如“导出我的所有发票”，你把参数改成别人的ID，就能拿到别人的发票列表。再配合身份证号、手机号这些字段，撞库、社工、精准诈骗全来了。

修复方案其实不复杂。服务端永远不要信任前端传的ID，从认证上下文里取当前用户。每个查询都加一层WHERE user_id = ?。要是非要用前端参数，也得先校验归属权。但现实是，很多老系统的接口散落在各个业务模块，改起来牵一发动全身，于是就一直裸奔。

我自己挖过几个这类漏洞，印象最深的是个医疗APP。查看检查报告的单据详情接口，reportId是自增的。我把自己报告ID减1，就看到了另一个患者的HIV检测结果。那个瞬间我后背发凉——这要是被别有用心的人批量拉取，就是一场社会事件。

所以别小看平行越权，它不像SQL注入那么“炫技”，也不像RCE那么致命，但它像慢性渗水，一滴一滴漏着用户的信任。有些厂商在等保测评里才想起来补，有些则等到上了热搜才紧急修复。可数据一旦泄露，删库跑路都来不及。

写代码的时候多想一步“这个请求到底该给谁看”，比事后打补丁便宜得多。