一个下午，越权漏洞我登录了某个电商后台，越权漏洞把URL里的越权漏洞订单号“10086”改成“10087”，页面刷新，越权漏洞另一名用户的越权漏洞收货地址、手机号、越权漏洞历史订单瞬间铺满屏幕。越权漏洞没有验证，越权漏洞没有拦截，越权漏洞连个弹窗警告都没有。越权漏洞这不是越权漏洞电影桥段，这是越权漏洞越权漏洞最典型的模样——它存在于大量业务系统里，安静得像一颗定时炸弹。越权漏洞

越权的越权漏洞本质，是越权漏洞系统把“身份验证”和“权限控制”混为一谈。你登录了，系统知道你是谁，但压根没想过你“能做什么”和“不能做什么”。开发图省事，前端隐藏按钮，后端只查一次登录态，参数一改，数据就漏了。我见过不少团队，安全测试只测登录框和SQL注入，对越权视而不见，因为他们默认“登录了就是自己人”——这种想法天真得让人后背发凉。

横向越权和纵向越权是两个孪生兄弟。横向的，是普通用户A能看普通用户B的数据，靠改ID就能串门；纵向的，是普通用户能调管理员接口，比如把请求里的“role=user”改成“role=admin”，服务器居然就信了。更隐蔽的是第三种——逻辑越权，它不靠改参数，而是靠绕过流程。比如某支付系统，你下单后不点“确认支付”，直接调用“查询订单状态”接口，发现状态字段默认是“已支付”，于是白嫖成功。这种漏洞最气人，因为代码逻辑本身没错，错在业务设计时没考虑“状态跳跃”的可能性。

说个我亲历的案例。某SaaS平台，客户能上传Excel批量导入员工信息。我随手把导入接口里的“company_id”从自己公司的换成竞争对手的，结果返回了对方全量员工名单，包括身份证号和工资条。更离谱的是，对方公司压根没开通这个功能，但接口没做归属校验，数据就这么裸奔出来了。修复方案很简单，后端强制从session取company_id，而不是信任前端传参——就这么一行改动，安全团队拖了三周才排期。为什么？因为产品经理觉得“没人会闲到去改参数”，这种侥幸心理，比漏洞本身更致命。

别以为只有小厂才会犯这种错。某头部社交软件早年也出过类似问题：通过修改朋友圈评论接口的ID，能删除任意用户的评论。他们后来补上了，但补丁只覆盖了“已删除”状态，没料到有人用“已删除”的评论ID去请求“恢复”接口，结果又把别人的评论给捞回来了。你看，越权漏洞就像地鼠，你打掉一个，它从另一个洞冒出来，因为根子上的问题没解决——权限校验必须集中、统一、不可绕过。

我自己的习惯是，拿到任何接口，先问三个问题：这个操作需要什么角色？这个数据属于哪个用户？服务器是否验证了这两点？如果答案是“前端做了限制”或“数据库里有个字段标记”，那基本可以断定有越权风险。防御其实不复杂，核心就两条：后端对每个请求做资源归属校验，以及把权限判断单独抽成公共方法，别散落在各处。但现实是，很多团队连接口清单都没整理过，更别说做权限矩阵了。

最后说句掏心窝子的——越权漏洞之所以泛滥，不是技术门槛高，而是开发者懒。懒得分清“登录”和“授权”，懒得多写一行校验代码，懒得上线前用两个账号交叉测一遍。你省下的那几分钟，迟早会变成甲方爸爸的怒火、用户的投诉，或者某个黑客在暗网叫卖的数据包。写代码的时候多问一句“这个请求换个人来发会怎样”，比什么安全扫描器都管用。