越权访问漏洞全解析：从原理到代码修复的实战指南

做Web开发这些年，我见过太多系统倒在“越权访问”这个坎上。你说SQL注入、XSS这些漏洞，多少还有WAF和安全工具帮你挡一挡，但越权访问这东西，它藏在业务逻辑代码里，任何通用安全设备都看不出来，只有从代码层面才能真正堵死它。

越权访问说起来也很简单：用户A明明只能看自己的订单，结果他改一下请求里的订单号，把用户B的订单给翻出来了；普通用户把某个参数一换，直接调通了管理员的删除接口。这类漏洞在OWASP里有个专门的分类叫IDOR（不安全的直接对象引用），后来业界又细化出水平越权和垂直越权，再后来还出现了BOPLA（对象属性级授权缺陷）这类更细的分支。不管叫什么名字，本质都差不多——服务端在授权和数据归属校验上存在缺失。

这篇文章我不打算空谈理论，而是从一个开发者和安全从业者的双重视角，把越权访问漏洞从原理到代码实现、从测试方法到踩坑复盘，全部捋一遍。内容主要面向后端开发、全栈工程师和安全测试人员，如果你正在维护用户系统、电商系统、SaaS平台这类带账号体系的应用，这篇文章尤其值得看完。

1. 越权访问漏洞的底层原理与分类

1.1 什么是越权访问：水平越权与垂直越权

越权访问漏洞，翻译成大白话就是：系统没有校验“当前用户对目标资源是否有访问权限”，导致用户可以访问或操作不属于自己的数据、功能。

它分两大类，这两类的成因和修复思路完全不同，先把这个搞明白，后面写代码才不会跑偏。

第一类是水平越权。同一个权限级别内，用户A访问了用户B的资源。最常见的场景就是订单查询、用户资料查看、文件下载。比如你的系统里有个接口是用订单ID查订单详情，如果后端只校验了“用户是否登录”，没有校验“这个订单是不是当前用户的”，那攻击者把订单ID从1001改成1002、1003、1004，循环遍历一遍，就能把全平台的订单数据拖走。这类漏洞在绝大多数系统里都存在过，尤其是那些用自增主键当业务ID的系统，简直一抓一个准。

第二类是垂直越权。低权限用户访问了高权限功能。典型场景是后台管理系统，普通注册用户直接构造管理员接口的请求，比如/api/admin/user/delete?userId=10086，如果后端没有做角色权限校验，普通用户也能把这个请求发出去执行删除操作。垂直越权的本质是功能级授权缺失，跟数据归属无关，解决思路是RBAC（基于角色的访问控制）。

理解这个区别特别重要，因为水平越权的修复关键在“数据归属校验”，垂直越权的修复关键在“角色权限校验”。两把锁各管一摊，缺一个都不行。

1.2 为什么越权漏洞如此普遍

越权漏洞可以说是Web应用里最隐蔽、也最容易出现的漏洞之一。做了这么多年代码审计，我总结出几个核心原因：

第一，开发时以功能实现为导向。产品经理说要做个订单查询页面，后端同学立刻写接口，能查出来就交差了。很少有人会停下来想一想：“这个订单到底应该谁能看？”

第二，很多团队只做了认证没做授权。登录逻辑做得花里胡哨，短信验证、扫码登录、OAuth接入全上了，但登录之后所有接口都能调。认证解决的是“你是谁”，授权解决的才是“你能干什么”。

第三，前端隐藏不等于后端安全。很多管理后台把删除按钮、导出按钮根据角色隐藏了，开发者就觉得“普通用户看不到按钮就操作不了”。实际上攻击者根本不看页面，直接用Burp Suite发一个HTTP请求就绕过前端了。

第四，数字ID这类可枚举的对象引用。自增主键、可预测的订单号、连续的编号规则，加上循环遍历，攻击者分分钟把全站数据拖走。我在代码审计时看到表格里的自增主键直接暴露给前端，心里就会咯噔一下。

第五，多租户系统的隔离问题。SaaS平台里租户A的数据被租户B访问到，这也是一种越权，而且影响面更广。之前很火的某多租户低代码平台漏洞，本质上就有相当一部分是越权问题——租户上下文没有在数据查询链路里正确传递。

1.3 影响范围与恶性程度

越权漏洞的影响面取决于系统里存了什么数据。电商系统可能泄露订单、收货地址、手机号；SaaS系统可能泄露企业客户数据；后台管理系统可能被垂直越权一锅端。最严重的情况是可以直接篡改或删除数据，比如越权改订单状态、越权修改用户余额、越权删除文件。

跟SQL注入这类漏洞相比，越权漏洞更难被通用安全工具发现。因为它是业务逻辑层的漏洞，需要理解业务语义才能判断“这个用户有没有权限干这件事”。这也是为什么它能在各大SRC平台的漏洞报告里常年霸榜。现实中很多大厂都栽过这个坑：某云盘因为修改UID参数遍历用户文件出事，某电商平台因为替换订单ID泄露用户隐私被通报，某社交平台因为未校验图片归属导致私密照片泄露。说它是高危漏洞里的“隐形杀手”，一点不过分。

2. 封死越权的底层设计：从架构层面规划鉴权与授权

2.1 认证与授权必须分开设计

这是我在代码评审时最爱问的问题之一：你的系统里，认证和授权是分开的模块吗？

遗憾的是，很多系统的答案是否定的。它们把“登录”当成安全性的全部——用户能登录进去，框架自动带上一个Session或Token，然后所有接口都能调。这就埋下了越权的地雷。

正确的做法是在架构设计阶段就把这两件事分开：

认证负责确认当前用户是谁，产出当前用户上下文（UserContext）。这一步通常在网关层、过滤器或拦截器里完成，一次登录后把用户ID、角色等基础信息塞进上下文，供后续使用。

授权负责确认当前用户能不能干这件事、能不能访问这个数据。这一步必须在业务调用链路上完成，而且要有统一的校验机制，不能指望每个开发在写接口时都自己想起来做权限判断。

代码结构上，我会把认证放在最外层的过滤器中，把授权拆成两层：功能级授权放在接口入口处（Controller层或网关层），数据级授权放在业务核心处（Service层）。这样设计的好处是