API越权修复后如何设计回归测试?

越权漏洞修复后，回归测试最容易犯的错误是拿原来越权请求重放一遍，看到返回 403 或 404 就认为问题已关闭。这种做法只能证明"那一条请求被拦住了"，无法证明授权逻辑在服务端真正生效，更无法防止修复不完整或引入新问题。有效的回归测试，核心在于验证三件事：未授权访问被拒绝、合法访问未被误伤、修复没有只停留在前端或单一路径。

回归测试的第一步，是复用原始测试条件建立基线。这里的关键是"复用"而非"重新构造"。应使用修复前发现漏洞时的同一组测试账号、同一批测试对象和同一环境，保证账号 A 访问对象 order_b 这个原始场景能够精确复现。如果测试账号被重置、对象被清理或环境版本变更，回归结果就失去了对照意义。在发送越权请求之前，先让合法账号访问自身对象，确认正常业务路径没有因修复而受损——这是最容易被跳过的一步，却恰恰是判断修复质量的重要参照。

第二步是围绕授权边界做系统性验证，而不是只测原始漏洞点。对象级授权修复后，应检查同一接口在不同对象、不同方法下的表现：账号 A 读取 order_b 被拒绝后，还要确认账号 A 能否修改、删除或导出 order_b；如果接口存在多个版本或网关路径，要逐一验证认证与授权策略是否一致。功能级授权同样如此，一个管理接口修复后，应分别用未登录、普通用户、受限角色和管理员账号请求，确认只有具备权限的角色能执行操作。响应判断不能只看状态码，403、404 和 401 在不同场景下都可能合理，关键是结合响应体、审计日志和服务端实际变化来确认拒绝决策确实生效。

第三步是检查响应字段和日志记录。即使越权请求被拒绝，响应中仍可能泄露对象是否存在、字段结构或内部错误信息；而合法请求的响应也可能因修复引入了不必要的敏感字段。应对比修复前后的响应体，确认未授权请求不返回对象内容，合法请求只返回角色应有的字段。同时检查审计日志中是否记录了拒绝决策的主体、对象、动作和结果，这既是修复生效的证据，也是后续追溯的依据。

回归测试的结论应明确区分"已修复""部分修复"和"未修复"。部分修复是常见情况：某个方法或版本已拦截，但相关入口仍可访问，或者对象级授权已修复而字段级暴露仍然存在。测试完成后，应清理测试产生的对象、令牌和临时配置，避免测试数据污染环境。只有未授权访问被拒绝、合法访问正常、日志记录完整、字段控制符合预期，才能判定问题真正关闭。