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

做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层）。这样设计的好处是，即使将来有消息队列、定时任务等新的调用入口，只要它们走Service层，数据级授权就不会被绕过。

2.2 RBAC与数据级权限：两把锁各管一摊

要封死越权，核心是上两把锁。

第一把锁是功能级权限，用RBAC解决。模型很简单：用户关联角色，角色关联权限。比如admin角色拥有user.delete权限，普通用户没有。落地方式通常是给接口打权限标识，然后通过注解或AOP统一校验。以Spring Security为例，在方法上标注@PreAuthorize("hasAuthority('user:delete')")，框架会在方法调用前拦截校验权限。

第二把锁是数据级权限，解决“这行数据是谁的”的问题。这个通常不能用RBAC解决，因为RBAC管的是“能不能操作某类功能”，管不到“能不能操作某条具体数据”。数据级权限的落地方式有两种：查询数据时强制带上当前用户的ID作为过滤条件，或者在访问数据前单独校验数据归属。

两把锁缺一不可。只上RBAC，普通用户虽然不能点删除按钮，但如果接口本身没有在Service层做数据归属校验，他依然可以通过伪造请求直接调用接口操作别人的数据；只做数据归属校验不做RBAC，那普通用户只要知道管理员的资源ID，照样能操作管理员的资源。

2.3 安全设计三原则：永远不信任前端、永远不信任参数、永远在服务端校验

这三句话老生常谈，但真正做到位的团队不多。我把它拆开来讲：

不信任前端：前端的按钮禁用、菜单隐藏都只是用户体验优化，不是安全控制。攻击者的请求根本不经过你的前端代码。前端可以防误操作，不能防攻击。

不信任参数：用户传入的ID、账号、订单号、文件路径等一切参数都可能被篡改。凡是涉及对象引用的参数，服务端都要判断当前用户是否有权限访问这个对象。参数里带了userId就要警惕，带了role=admin更要警惕。

永远在服务端校验：所有关键操作必须在服务端做二次校验。前端可以做校验和提示，但最终的安全边界在服务端。前端的校验做得再好看，服务端不校验等于零。

这三个原则不光是代码层面的约束，更应该是设计评审时的检查项。每次新接口设计评审，我都会拿着这三个原则过一遍，能筛掉一大批低级问题。

3. 代码层面的关键实操：防越权校验的落地实现

3.1 通用防越权校验组件：从请求上下文获取当前用户

在实际项目中，我会把权限校验做在几个统一的层面，而不是散落在各个接口里。最基础的一步是拿到“当前用户是谁”。

以Java Spring Boot为例，通常的做法是在拦截器里解析登录态，然后把用户信息放进ThreadLocal或请求上下文中。后续的业务代码随时可以取到当前用户ID。一个简单的实现：

java复制public class UserContext {
    private static final ThreadLocal<CurrentUser> HOLDER = new ThreadLocal<>();

    public static void set(CurrentUser user) {
        HOLDER.set(user);
    }

    public static CurrentUser get() {
        return HOLDER.get();
    }

    public static Long getUserId() {
        CurrentUser user = HOLDER.get();
        return user == null ? null : user.getId();
    }

    public static void clear() {
        HOLDER.remove();
    }
}

拦截器负责从Token或Session中解析用户信息，写入UserContext：

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        String token = request.getHeader("Authorization");
        // 解析token，校验签名和有效期
        CurrentUser user = tokenService.parseToken(token);
        if (user == null) {
            throw new UnauthorizedException("未登录或登录已过期");
        }
        UserContext.set(user);
        return true;
    }

    @Override
    public void afterCompletion(...) {
        UserContext.clear(); // 防止线程复用导致数据串号
    }
}

这里有个非常关键的坑：用ThreadLocal存用户信息，一定要在请求结束时清理，否则在高并发场景下线程池复用线程，上一个请求的用户信息会串到下一个请求里。我见过线上事故就是漏了这一行清理代码，导致用户A的请求查出了用户B的数据——这本身就是一种越权。

3.2 数据归属校验：操作资源前先校验owner

这块是防水平越权的核心。最常见的做法是：在业务代码里，凡是根据ID直接操作数据的地方，都要校验这条数据的owner是不是当前登录用户。

我推荐一个简单有效的写法：在Service层写一个通用的资源归属校验方法，比如assertResourceOwnership，或者在DAO查询层直接就把userId作为查询条件拼进去。

第一种是“查出来再校验”，第二种是“查询时就把owner带上”，不让越权的数据有被查出来的机会。两种写法在性能上也有区别——第一种要查出来后做一次比对，第二种在SQL层面就直接过滤掉了。我强烈推荐第二种，既安全又高效。

以订单查询为例，错误写法：

java复制public Order getOrderById(Long orderId) {
    return orderMapper.selectById(orderId);
}

正确写法：

java复制public Order getOrderById(Long orderId) {
    Long currentUserId = UserContext.getUserId();
    Order order = orderMapper.selectByIdAndUserId(orderId, currentUserId);
    if (order == null) {
        throw new ForbiddenException("无权访问该订单");
    }
    return order;
}

对应的MyBatis Mapper XML：

xml复制<select id="selectByIdAndUserId" resultType="Order">
    SELECT * FROM orders 
    WHERE id = #{orderId} AND user_id = #{userId}
</select>

这样即使orderId被篡改了，只要它不属于当前用户，SQL查询返回空，业务自然就中断了。订单表要给user_id加索引，否则大表场景下这个查询会很慢。我自己踩过这个坑，加索引前后查询耗时差了三个数量级。

3.3 用注解统一拦截：避免每个接口重复造轮子

如果一个系统里有几百个接口，靠人肉在每个方法里写校验，肯定有漏网之鱼。所以更稳妥的做法是抽象出一个统一的权限校验层，让规范约束住大多数人。

我在项目里常用的方案是自定义注解加AOP切面。先定义一个权限注解：

java复制@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RequiresPermission {
    String value(); // 权限标识，如 "user:delete"
}

再写一个AOP切面统一拦截：

java复制@Aspect
@Component
public class PermissionAspect {
    @Before("@annotation(requiresPermission)")
    public void checkPermission(JoinPoint joinPoint, RequiresPermission requiresPermission) {
        CurrentUser user = UserContext.get();
        // 查询当前用户的角色和权限列表（一般会做缓存）
        Set<String> permissions = permissionService.getUserPermissions(user.getId());
        if (!permissions.contains(requiresPermission.value())) {
            throw new ForbiddenException("无权限执行该操作");
        }
    }
}

这样每个接口只需要标注权限码，不用重复写校验逻辑：

java复制@RequiresPermission("order:delete")
@PostMapping("/api/order/delete")
public Result deleteOrder(@RequestParam Long orderId) {
    orderService.deleteOrder(orderId);
    return Result.success();
}

这里要注意，AOP只能拦截走代理的方法调用。如果同一个类内部直接调用被注解标注的方法，AOP是不生效的。我见到过不少团队在排查问题时才发现这个坑——一个类里的方法A调用方法B，方法B上面标了权限注解但没触发，因为调用发生在类内部，没走代理。

3.4 JWT与Token场景下的越权风险与正确打开方式

现在很多系统用JWT做登录态。JWT本身和越权没有必然关系，但如果用得不规范，会引入一种非常典型的越权漏洞。

第一个风险是签名算法混淆。攻击者把JWT头部的alg字段改成none，或者改成对称加密算法HS256，而服务端如果没做算法白名单校验，就能伪造任意用户身份。这是经典的JWT漏洞，在不少CTF题目和靶场里都能复现。解决方案很简单：服务端必须严格校验alg字段，只允许预期的算法。

第二个风险是密钥泄漏或弱密钥。有些团队把JWT密钥写在代码里、提交到Git仓库，或者用一个极其简单的字符串当密钥，比如secret、123456。攻击者拿到密钥后可以自己签发管理员Token。解决方法是使用足够强度的随机密钥，并通过环境变量或密钥管理服务注入，定期轮换。

第三个风险是过期时间失效。服务端没有校验exp字段，导致旧Token永久有效。更隐蔽的是，用户离职了、角色被降级了，但Token里的角色信息还是老的，系统又以Token里的角色信息为准做权限判断，导致被降权的用户继续拥有高权限。正确的做法是：核心权限判断不要只依赖Token里的声明，要从数据库读取最新的角色权限，Token里只放用户ID这类稳定标识。

正确的JWT使用姿势我总结成几条：

• payload里不放敏感数据，只放用户ID、Token版本号等非敏感声明
• 服务端强制校验签名、校验过期时间、校验算法白名单
• 设置合理的过期时间（Access Token短一点，Refresh Token配合使用）
• 提供Token主动失效机制，比如服务端维护一个黑名单或token版本号
• 核心权限动态从数据库读取，不依赖Token里缓存的角色信息

3.5 文件下载、批量接口与多租户场景的越权

文件下载是越权重灾区。很多系统把文件URL或者文件路径直接作为参数，比如/download?filename=2024/01/report.pdf，服务端拿到filename拼路径就去读文件。攻击者把filename改成别人的文件路径，甚至改成../../etc/passwd做路径穿越，就把不该看的内容全拖走了。

封死这类问题的办法有几条：

• 不要暴露真实文件路径，用文件ID代替。前端拿到的是/download?fileId=abc123，服务端通过fileId查文件记录，校验归属后再返回文件流
• 下载接口同样要校验当前用户是否有访问该文件的权限，不能只校验登录态
• 对文件名做白名单校验和路径规范化处理，杜绝路径穿越

批量接口也要格外小心。常见的导出、批量删除、批量修改，如果只校验“登录用户”不做数据范围校验，攻击者可以传入大量他人ID批量操作。我的习惯是：批量操作接口的入参不直接接受业务ID列表，而是接受“查询条件+操作指令”，真正涉及哪些数据由服务端根据当前用户的数据权限去匹配。比如批量删除订单，前端传“删除我名下所有已完成订单”，服务端在SQL里强制拼上user_id = 当前用户ID，从根源上杜绝了传入他人订单ID的可能。

多租户场景还要额外注意租户上下文。很多SaaS系统的表设计里都有tenant_id字段，但代码里如果忘记把当前租户ID拼进SQL，租户A就能查到租户B的数据。我的建议是：租户ID不能从请求参数里取，必须从Token或上下文中取，并且在DAO层做全局拦截，统一拼上租户条件，避免每个开发自己写。

4. 越权漏洞测试方法与自查清单

4.1 手工测试：改ID、改角色、改参数三板斧

越权漏洞的手工验证其实很简单，核心思路就是“改参数，看响应”。拿正常请求后，用Burp Suite抓包拦截请求，或者直接改前端请求参数，把请求里的ID替换成其他用户的数据，观察响应是否返回了不该返回的内容。如果返回了，那基本就是水平越权。

具体操作流程大概是这样的：

1. 准备两个测试账号，比如userA和userB，最好在数据库里能看到他们各自的资源ID
2. 用userA登录，抓一个查询详情的请求，比如/api/order/detail?orderId=1001，正常响应里能看到userA的订单数据
3. 把orderId改成userB的订单ID，比如1002，重新发请求
4. 如果响应里返回了userB的订单信息，水平越权实锤

垂直越权的测试思路类似：

1. 用管理员账号登录，抓一个管理接口的请求，比如/api/admin/user/delete?userId=10086
2. 退出管理员，换普通用户登录，把同样的请求重新发一遍
3. 如果返回200而不是403，垂直越权实锤

这里有个小技巧：实测时优先关注那些带ID参数的GET请求、导出功能、文件下载功能，这些是最容易出现越权的点。POST接口也要测，尤其是那些带对象ID的JSON请求体，不一定比GET接口安全。

这类测试在DVWA、Pikachu这些渗透测试靶场里都有专门的演练模块，很适合新手练手。练熟了再拿真实系统测试，思路基本是相通的。

4.2 自动化扫描与代码审计：越权为什么难被扫出来

越权漏洞和SQL注入有个很大的区别：SQL注入可以通过检测报错信息、响应延迟等特征来自动化发现，但越权漏洞没有任何“特征”，它的判断逻辑是“这段数据该不该被这个用户看到”，这是纯粹的业务语义问题。

所以你会发现，很多通用漏洞扫描器对越权几乎无能为力。它们可以扫出SQL注入、XSS、暴露的配置文件，但扫不出业务逻辑漏洞。我在实际项目里主要靠两件事补位：

一是代码审计。代码审计的重心放在：

• 搜索接口方法中是否直接用对象ID参数查询数据，且没有归属校验
• 检查是否每个关键接口都有权限校验注解或拦截器
• 检查Service层的查询SQL是否带上了用户ID或租户ID作为过滤条件
• 检查文件下载、批量操作、状态变更等特殊接口是否做了完整校验

二是半自动化的辅助脚本。业界有一种做法是“爬接口+改参数重放”，对同一接口用两个不同用户的Token分别请求，对比响应差异。这个思路可以做成半自动工具，但落地起来工作量不小。也可以借助GVM这类开源漏洞扫描平台做常规漏洞覆盖，但逻辑漏洞还是得靠人工代码审计加手工测试。

4.3 自查清单：上线前照这个表过一遍

我把平时排查越权时用的清单整理成了一张表，开发自测、代码评审、安全验收都可以直接拿来用：

这张表我建议做成团队安全评审的标准动作，每次新功能上线前逐项打勾。别嫌麻烦，我发现很多线上越权漏洞，在评审阶段只要认真过这张表都能提前拦住。

5. 常见问题与排错实录

5.1 排查实录：一次订单查询接口的越权修复复盘

讲一个真实案例。之前我们系统上线了一个订单详情接口，当时只校验了“用户是否登录”，没有校验“这个订单是不是当前用户的”。上线后运营反馈“用户反馈看到了别人的订单”，一查日志，确实有用户在短时间内通过修改订单ID参数遍历出了一批不属于自己的订单。

排查过程是这样的：

1. 先复现。用测试账号A登录，抓包修改订单ID，发现能查到账号B的订单，确认水平越权
2. 再看代码。定位到Controller和Service后发现，Service层用orderMapper.selectById(orderId)直接查的，没带用户ID条件
3. 修复。把查询SQL改成selectByIdAndUserId(orderId, userId)，同时给orders表的user_id字段补充索引
4. 回归测试。用账号A重新请求账号B的订单ID，返回无权访问；正常请求自己的订单，逻辑不受影响
5. 全库自查。把系统里所有按ID直接查询数据的接口都过了一遍，找出同类问题一并修复

这个案例里最值得反思的一点是：这个漏洞不是恶意攻击者发现的，而是正常用户不小心改了个参数发现的。这恰恰说明越权漏洞的触达门槛有多低——不需要黑客技术，只需要手欠改一下参数。这也是为什么必须从代码层面去堵，而不是指望攻击者不会发现。

5.2 为什么加了权限校验还是被越权？

这个问题我遇到太多次了，最后排查出来的原因基本都逃不过这几类：

缓存问题：权限校验读的是缓存里的旧角色数据，用户角色变更后没有及时刷新缓存，导致被降权的用户依然拥有高权限。解决方案是角色变更时主动清除对应用户的权限缓存。

校验只做了一半：校验逻辑只写了“判断是否登录”，没写“判断是否有权限”；或者只校验了Controller层，没校验Service层。定时任务、消息队列、RPC内部调用等入口如果直接绕过Controller调用Service，就能跳过权限校验。修复思路是“核心业务逻辑的校验下沉到Service层”。

批量接口漏网：很多团队只给单条接口加了归属校验，批量接口忘了。攻击者只要走批量接口就能绕过。这个只能通过自查清单来兜底。

用了可预测的对象ID：即使做了归属校验，如果对象ID是自增数字，攻击者依然可以通过遍历ID来猜。但这至少比直接查出来要安全，因为每次请求都会被拦；更彻底的方案是换用UUID或雪花ID这类不可枚举的标识。

校验逻辑本身有bug：比如用==比较包装类型的用户ID而不是用equals，导致永远不相等或永远相等。这种问题在代码评审时要特别留意。

5.3 给新人的三步排查法

如果你怀疑自己的系统有越权漏洞，但不知道从哪里下手，我强烈建议按这个顺序排查：

第一步，画出系统的接口清单。把所有接口按“是否需要登录、是否管理接口、是否接收对象ID参数”打标签，重点标出那些接收对象ID的接口。

第二步，找出所有接收对象ID的接口，逐个测试修改ID后是否存在越权。这个测试不一定要用什么工具，浏览器开发者工具改请求重放都行。

第三步，对发现的越权问题，先判定是水平越权还是垂直越权，再针对性地修复。水平越权补数据归属校验，垂直越权补RBAC功能权限校验。

按这三步走下来，基本能覆盖系统里90%以上的越权问题。剩下那10%，藏在一些特殊的业务场景里，比如跨租户的数据引用、审批流里的越权操作、批量导入导出等，这些就要靠对业务的理解和更细致的代码审计来补了。

写在最后的体会

做安全这块时间长了，我越来越觉得越权漏洞是个很特别的存在。它不像SQL注入那样有酷炫的攻击姿势，也不需要复杂的漏洞利用链，就只是悄无声息地藏在一行普通的查询代码里。攻击者改一个参数，就能突破数据的边界。

我个人在做代码评审时，养成了一个习惯：每次看新接口，先问自己三个问题——这个接口的权限声明清楚了吗？操作的数据有没有做归属校验？如果我是攻击者，我能通过改参数访问到别人的数据吗？这三个问题问下来，大量越权漏洞在上线前就被拦住了。这个习惯我也建议你试试，不夸张地说，它比很多安全测试工具都好用。

最后再分享一个小技巧：写完业务代码后，试着用两个账号各跑一遍你的接口——账号A创建资源，账号B去访问，看能不能访问到。这比写什么单元测试都直观。越权访问看着简单，但它坑过太多开发团队了。代码层面多上几道锁，这个坑还是能稳稳填平的。