ChatGPT、Codex安全实战：接口已经校验登录，为什么用户还能查到别人的订单？

一个Java开发人员最近在维护一个Spring Boot订单系统。项目已经接入JWT身份认证，用户登录后才能访问订单接口，未登录请求会直接返回401。

从安全检查来看，认证机制似乎没有问题。

但在一次接口测试中，开发人员发现了一个奇怪的现象：用户A登录后，可以正常查询自己的订单。如果把请求地址中的订单ID换成用户B的订单ID，接口竟然仍然返回200，订单详情也完整地展示出来了。

更麻烦的是，类似的问题不只出现在订单详情接口。修改订单、查询订单附件，甚至导出订单数据，都可能出现相同的问题。

开发人员最初怀疑是JWT校验出了问题，于是检查Token解析、登录状态和Spring Security配置，发现这些机制都在正常运行。

为什么已经登录的用户，还能访问别人的数据？

问题其实不在于系统有没有验证用户身份，而在于系统验证了访问者是谁，却没有进一步验证这个人是否有权访问当前请求的资源。

这类问题通常被称为对象级授权缺失，也就是常说的IDOR或BOLA漏洞。

它是很多后端接口容易忽略的安全边界。尤其是在使用ChatGPT、Codex批量生成Controller、Service和Repository代码时，如果Agent只关注接口能否正常运行，而没有检查每个资源的访问权限，就可能把这个漏洞带进生产环境。

一、先判断问题：登录成功不代表有权访问所有订单

先看一个典型接口。

系统提供订单详情查询：

GET /api/orders/10001
Authorization: Bearer 用户A的Token

服务端完成JWT校验，确认用户A已经登录，然后根据订单ID查询数据库。

如果数据库中存在这条订单，接口就返回详情。

问题就在这里：系统只判断了订单是否存在，却没有判断订单属于谁。

假设数据库中有两条记录：

用户A访问10001，应该返回自己的订单。

但当用户A将请求改为10002时，如果服务端仍然只按照订单ID查询，那么数据库会正常返回用户B的订单。

从程序执行角度看，SQL没有报错，JWT也验证成功，接口自然返回200。

但从权限控制角度看，这就是一个严重的安全问题。

这里必须区分两个概念：

身份认证（Authentication）：确认当前访问者是谁。

资源授权（Authorization）：确认当前访问者是否有权执行当前操作。

JWT解决的是身份识别问题，并不会自动替你判断用户是否拥有某个订单。

Spring Security能够帮助项目建立认证和授权机制，但如果开发人员只配置了登录拦截，没有针对具体订单、文件和业务对象进行权限判断，仍然可能出现越权访问。

因此，看到接口返回200时，不要只检查Token是否有效，还要继续检查服务端是否验证了资源归属关系。

二、表层原因：为什么很多项目只校验登录，却漏掉资源权限？

在实际开发中，问题经常出现在下面几种写法中。

第一种，Controller已经获取当前用户，但查询订单时没有使用用户身份。

第二种，Service只接收订单ID，完全不知道当前操作人是谁。

第三种，Repository提供了根据ID查询的方法，开发人员直接调用，没有附加用户归属条件。

例如：

public Order getOrder(Long orderId) {
return orderRepository.findById(orderId)
.orElseThrow(() -> new RuntimeException("订单不存在"));
}

这段代码本身没有语法错误，也能够正常工作。

但它只回答了一个问题：订单是否存在。

它没有回答另一个更重要的问题：当前用户是否拥有这笔订单？

如果整个项目大量采用这种查询方式，那么即使登录认证做得非常完整，也无法阻止用户通过修改资源ID访问其他人的数据。

还有一种更隐蔽的情况：前端已经隐藏了其他用户的订单入口，开发人员便认为权限控制已经完成。

但前端控制只是交互层面的限制，用户可以直接使用浏览器开发者工具、Postman或者脚本构造请求。

真正的资源授权必须在服务端执行，不能依赖前端隐藏按钮或限制页面入口。

三、深入机制：BOLA漏洞到底发生在哪个环节？

BOLA，全称Broken Object Level Authorization，指对象级授权失效。

它的核心问题不是用户没有登录，而是服务端在访问具体业务对象时，没有正确执行对象级权限检查。

可以把一个典型请求拆成三个阶段：

很多存在漏洞的项目，只完成了第一步和第二步。

第三步被遗漏了。

为什么这种问题容易出现？

因为开发人员经常把资源ID当成普通查询参数，而没有把它看成一个需要授权的访问目标。

例如，订单详情、用户资料、发票文件、项目记录和业务附件，都可能通过ID进行定位。

只要服务端允许用户通过修改ID直接访问对象，而没有检查对象归属或授权关系，就可能出现越权。

还有一个容易误解的地方：把自增ID改成UUID，并不能从根本上解决这个问题。

UUID确实可以降低资源ID被连续猜测的可能性，但它解决的是资源标识的可预测性，不是访问权限。

如果一个用户通过其他途径拿到了别人的UUID，服务端仍然允许直接访问，那么漏洞依然存在。

资源ID是否容易猜测，与用户是否有权访问资源，是两个完全不同的安全问题。

四、最快排查：先检查这4个位置

如果项目已经出现用户能够读取其他用户订单的情况，不建议一开始就重构整个权限系统。

先沿着请求链路检查四个位置。

第一，检查Controller是否正确获取当前用户。

确认当前用户身份来自经过验证的SecurityContext或可信的认证上下文，而不是客户端自行提交的userId。

第二，检查Service是否传递了用户身份。

如果Service只有订单ID，没有当前用户或授权上下文，就要进一步确认权限判断究竟在哪里完成。

第三，检查Repository查询条件。

重点查看是否只有：

SELECT *
FROM orders
WHERE id = ?;

如果查询只根据订单ID定位，就要确认后续是否存在可靠的资源授权检查。

第四，检查所有相关接口。

不能只检查订单详情，还要检查修改、删除、导出、附件下载、批量查询等接口。

尤其要注意，有些项目详情接口已经增加权限判断，但导出接口仍然直接根据订单ID读取数据。

这会形成一个很典型的安全盲区：页面看起来已经修复，实际数据仍然可以通过其他入口获取。

排查时建议记录接口路径、当前用户ID、目标资源ID、目标资源所属用户ID和最终授权结果。日志中不要记录完整Token、密码或不必要的敏感业务数据。

五、具体解决：把资源归属条件放进服务端查询

对于普通用户只能访问自己订单的场景，一个直接有效的办法，是让查询条件同时包含资源ID和当前用户ID。

例如，将原来的查询改成：

public Order getOrder(Long orderId, Long userId) {
return orderRepository
.findByIdAndUserId(orderId, userId)
.orElseThrow(() -> new NotFoundException("订单不存在"));
}

Repository对应的查询可以理解为：

SELECT *
FROM orders
WHERE id = ?
AND user_id = ?;

这样，即使用户A修改了订单ID，查询条件也必须同时满足：

订单ID正确，并且订单所属用户必须是当前登录用户。

如果订单属于用户B，查询就不会返回对应记录。

这里还有一个重要细节：userId必须从服务端可信的身份上下文中获取，不能直接相信客户端请求体中的userId。

否则，攻击者只需要把请求中的userId从A改成B，就可能绕过原本的权限限制。

对于修改订单的操作，也可以采用带有归属条件的更新：

UPDATE orders
SET remark = ?
WHERE id = ?
AND user_id = ?;

这样能够避免只凭订单ID修改其他用户的数据。

不过，更新影响行数为0时，还需要根据业务要求处理资源不存在、无权访问和状态冲突等情况。

对于不希望向外部暴露资源是否存在的接口，可以统一返回404；对于需要明确提示权限不足的内部系统，也可以根据安全策略返回403。

具体选择要保持整个系统的一致性，避免通过不同响应让外部访问者轻易枚举敏感资源。

六、多租户项目更复杂：用户属于同一个系统，也不代表能访问同一份数据

如果项目只是简单的个人订单系统，增加user_id条件可能就能解决主要问题。

但对于SaaS平台、企业管理系统和多租户业务，权限关系会更加复杂。

例如：

企业A下面有多个部门和员工，企业B也有自己的用户。

这时，不能只检查订单属于哪个用户，还需要检查当前用户属于哪个租户，以及他在租户内具有什么角色。

典型查询条件可能包括：

SELECT *
FROM orders
WHERE id = ?
AND tenant_id = ?
AND user_id = ?;

但这里也不能机械地要求每笔订单都只能由创建人访问。

因为实际业务可能存在管理员、部门负责人、客服人员和被授权协作人员。

正确做法是根据业务权限模型判断：

普通用户只能查看自己的订单；部门负责人可以查看授权范围内的订单；企业管理员可以查看所属租户的数据；跨租户访问必须经过明确的授权机制。

也就是说，资源授权不能简单理解为永远比较user_id，而应该根据用户身份、资源归属、角色和业务关系进行判断。

还有一个经常遗漏的地方：缓存。

假设系统使用Redis缓存订单详情，如果缓存Key只使用订单ID，而没有考虑用户权限或租户隔离，那么即使数据库查询已经增加授权条件，缓存层仍然可能出现数据串用。

类似地，文件下载地址、异步导出任务和批量操作也需要重新检查权限。

安全边界必须覆盖完整的数据访问链路，而不是只保护一个Controller方法。

七、让Codex修复越权问题，为什么不能只说增加权限校验？

如果直接告诉Codex：

“帮我修复订单接口的越权问题。”

Agent可能只修改发现问题的详情接口，却遗漏其他调用入口。

更稳妥的做法，是让它先梳理整个订单模块的资源访问路径。

可以要求Codex：

• 找出所有根据订单ID查询、修改、删除和导出的接口。

• 追踪当前用户身份从认证上下文传递到Service的过程。

• 检查Repository是否存在仅凭资源ID访问数据的查询。

• 梳理普通用户、部门管理员和租户管理员的授权边界。

• 找出缓存、附件和异步任务中的潜在越权入口。

• 先输出风险清单和修改方案，不要立即批量重构。

修改时，再让它围绕不同用户建立测试数据。

例如，创建用户A、用户B和两笔分别属于他们的订单，验证：

用户A可以查询自己的订单；用户A不能读取用户B的订单；用户A不能修改用户B的订单；用户A不能通过导出或附件接口获取用户B的数据；管理员只能在明确授权范围内访问数据。

这里尤其要注意，不能只让Codex检查代码中有没有userId判断，而要让它验证不同身份下实际返回的数据和业务结果。

八、修复后怎么验证？不能只看接口返回403

接口返回403不一定代表所有越权问题都已经修复。

有些接口虽然阻止了读取，却仍然允许通过修改请求参数执行更新。

还有些接口已经修复数据库查询，但缓存仍然可能返回其他用户的数据。

因此，验证应该覆盖不同资源操作和不同用户身份。

可以准备两名普通用户、一个管理员和两个不同租户，分别执行查询、修改、删除、导出和附件下载测试。

重点检查三类结果：

第一，正常授权请求是否仍然可以执行，不能因为修复越权而影响正常业务。

第二，未授权请求是否被服务端拒绝，并且没有产生数据库写入、文件下载或其他副作用。

第三，管理员、部门负责人和租户用户的授权范围是否符合真实业务规则。

还应该检查批量接口。如果一个请求中同时包含多个订单ID，不能只验证第一个订单的权限，而忽略其他订单是否属于当前用户。

对于涉及缓存和异步任务的接口，也要分别验证资源归属和任务发起人的身份。

真正的修复标准不是接口返回了403，而是未授权用户无法通过任何相关入口读取或修改目标资源。

九、Plus和Pro怎么判断？

如果平时主要让ChatGPT、Codex分析单个Spring Boot项目的Controller、Service和Repository，定位JWT认证与资源授权之间的问题，补充越权测试，Plus通常够用。

如果需要跨多个微服务、多个租户模块和复杂权限体系进行安全审查，还要让Codex持续分析大量代码、修改多个模块并运行回归测试，Pro更适合高频、长任务的工程工作流。

但需要注意，套餐本身不能替代专业安全审计。尤其涉及订单、支付、用户隐私和企业数据时，必须结合真实权限模型、测试环境和人工代码审查验证结果。

最后

接口已经校验登录，为什么用户还能查到别人的订单？

因为登录认证只解决了访问者是谁的问题，并没有自动解决访问者是否有权读取某个具体资源的问题。

真正需要检查的是：

身份认证是否可靠 → 资源归属是否明确 → 服务端是否执行授权 → 查询和修改是否带权限条件 → 缓存与导出是否存在绕过入口 → 修复后是否完成越权回归测试。

对于ChatGPT、Codex生成的后端代码，尤其要注意这一点：Agent能够快速生成登录拦截、JWT解析和数据库查询，却不一定能够自动理解企业内部复杂的资源授权关系。

安全问题往往不是接口不能运行，而是接口运行得太正常，却把不应该返回的数据返回给了错误的人。

更少猜测，更多证据，更好的工程。真正可靠的权限控制，不是证明用户已经登录，而是证明用户只能够访问自己有权访问的数据。

持续分享 Codex、大模型开发与 AI 编程实战内容

也整理了稳定的 Plus/Pro 会员订阅渠道，有需要可自取。