把越权用例写进接口回归测试

我以前做接口回归时，最容易漏掉的不是“没登录能不能访问”，而是“登录以后能不能访问不属于自己的对象”。接口带着有效身份，测试就顺手点了通过；可一旦把对象标识换成另一个用户的，问题才真正出现。这类失效对象级授权，也就是 BOLA，往往不需要绕过认证，安静得像一只没有留下脚印的猫。

所以我现在会把越权用例直接写进接口回归测试，而不是把它留给上线前的临时扫描。最小测试单元很简单：准备用户 A 和用户 B，用 A 的凭据访问 B 的对象，然后分别验证读取、修改和删除结果。读取不能拿到数据，修改不能改变状态，删除也不能影响 B 的对象。若系统选择把“无权访问”伪装成“对象不存在”，测试就应断言响应表现一致，避免调用者通过差异判断对象是否存在。

不只测详情接口

只测“根据 ID 获取详情”还不够。列表接口要验证服务端是否强制限制查询范围，不能因为客户端传入了某个用户、租户或组织标识，就看到别人的数据。更新接口要测试请求体里额外带入归属字段、角色字段时，服务端是否拒绝或忽略；响应还要确认内部备注、风控信息等不该暴露的字段没有被顺手返回。

批量接口和嵌套资源是我会重点补测的地方。批量删除不能只校验数组里的第一个 ID，混入一个不属于当前用户的对象时，整批操作应按设计拒绝。嵌套路径也不能只验证父对象属于当前用户，还要确认子对象确实属于这个父对象。文件下载、导出链接、内部接口同样不能因为“入口不公开”就跳过授权测试。

让测试跟着接口变化走

这类用例最怕写完就落灰。凡是新增或修改接口、认证方式、数据模型，都应同步更新受保护对象接口表，并在代码评审里写清楚归属字段和校验位置。回归测试的触发条件应该是“接口变了”，而不是“发版前突然想起来了”。

我会先从现有接口清单下手：凡是路径、查询参数、请求体或批量数组里出现对象标识，就补一组“A 访问 B”的测试。填不出归属关系和校验位置的接口，通常也正是最值得先测的接口。