API版本治理如何避免权限漂移

API 版本治理中，权限漂移往往是比接口下线更隐蔽的风险。它通常不是一次性的配置错误，而是多个版本并行演进时，权限中间件、网关路由和文档声明逐渐脱节的结果。一个典型的场景是：v1 接口在早期版本中只有匿名访问或宽松校验，后来团队在 v2 中补上了认证和对象级授权，但 v1 仍然在线运行，旧逻辑未被同步修复。此时文档可能已经更新为“要求认证”，线上 v1 却依然接受匿名请求，或者虽然要求认证，却绕过了新版本才引入的对象归属校验。

要识别这类漂移，不能只比较路径字符串或状态码。更有效的方式是建立一份统一的接口资产清单，把 OpenAPI 文档声明、网关日志中的实际流量、前端与移动端请求、路由注册表以及 CI/CD 构建产物合并到同一份记录中，并保留方法、路径、参数、认证要求和版本标识等规范化字段。有了这份清单，才能把接口分成三类来核对：文档有但线上无的，可能是已下线或部署版本不一致；线上有但文档无的，可能是隐藏接口或遗留路由；两边都有但定义不同的，则最值得警惕，因为参数、认证或权限策略很可能已经发生漂移。

验证权限漂移时，重点不是看 HTTP 状态码，而是看访问边界是否被真正改变。通常需要建立最小对照组：匿名请求、普通用户请求、管理账号请求，以及访问不属于当前用户的测试对象请求。如果文档声明某接口要求认证，但匿名请求返回了真实用户对象，这属于认证控制缺失；如果普通用户能读取另一测试用户的对象，则属于对象级授权缺陷。需要注意的是，有些系统会统一返回 200 搭配业务错误码，或对不存在的资源统一返回 404，因此判断依据应包含响应体是否泄露受保护字段、响应长度是否异常、审计日志是否记录了正确主体，以及不同身份下访问边界是否一致。

版本差异本身不等于漏洞。只有当差异改变了数据可见性、对象访问边界或操作权限时，才应升级为安全问题。判断时建议按固定顺序排查：先确认环境和基址，避免把测试环境差异误判为线上漏洞；再查看发布记录和路由注册，判断接口是否已废弃但仍被访问；然后确认认证层是在网关、服务中间件还是控制器执行；最后用同一测试对象重复验证，并由另一名人员复核。如果旧版本可访问但执行了与新版相同的权限校验，这属于版本治理问题，风险取决于数据敏感性和生命周期；如果旧版本绕过了新版本的权限校验，则属于版本暴露导致的访问控制缺陷，需要更高优先级处理。

修复建议不应只写“增加权限校验”。更具体的要求包括：授权决策必须在服务端完成，对象 ID 不能作为权限凭据，租户边界应从可信会话上下文取得，旧版本应完成下线、隔离或同步安全修复。整改后的回归测试应使用与初次发现相同的对象关系，并覆盖匿名访问、跨对象访问、管理账号访问以及 v1 与 v2 权限边界一致性等场景。最终交付的不应只是一个 URL 列表，而是一份能够解释接口来源、版本关系、参数约束、认证主体和权限边界的资产清单，这样才能把一次性的接口枚举推进为持续的版本治理。