API越权中的BOLA与BFLA

API 越权中，BOLA 与 BFLA 分别对应两类不同的授权失效：BOLA（Broken Object Level Authorization）关注“当前身份能否访问这个具体对象”，BFLA（Broken Function Level Authorization）关注“当前角色能否执行这个功能”。前者常发生在订单、项目、地址等对象标识可被客户端提交的场景；后者则常见于普通用户调用管理接口、执行导出、修改权限或其他超出角色职责的操作。

先区分对象与功能

如果账号 A 能读取账号 B 的订单，即使请求本身已经完成认证，也可能是 BOLA。问题核心在于服务端是否重新校验对象归属、租户边界或协作关系，而不是是否接受了某个对象编号。

如果普通用户能够调用仅限管理角色使用的成员管理、全量导出或配置变更接口，则更接近 BFLA。此时对象可能属于当前用户，真正失效的是功能级权限判断。隐藏前端按钮、限制路由或依赖接口路径命名，都不能替代服务端授权。

二者还可能叠加：用户先绕过功能权限进入管理接口，再通过对象参数读取其他租户数据，风险通常高于单一越权。因此测试时应分别建立对象授权假设和功能授权假设，避免把所有异常响应都笼统归为“权限问题”。

用最小化对照验证

在获得书面授权、使用测试账号和脱敏数据的前提下，先建立合法基线，再进行单变量对照。BOLA 可由账号 A 访问自身对象、随后访问账号 B 对象来验证；BFLA 则应比较未登录、普通用户、受限角色和管理测试账号对同一功能的行为。优先使用只读接口，不进行大范围枚举，也不要擅自测试删除、支付、改密和批量导出。

判断依据不能只有状态码。应同时检查响应中的对象标识、用户或租户标识、敏感字段、业务错误信息、审计日志以及是否产生实际状态变化。未授权请求即使返回 200，只要泄露对象内容或执行了越权动作，仍可能构成问题；返回 403 或统一的 404 也必须结合业务规则解释。

修复应落在服务端：根据认证主体重新加载对象并执行授权检查，对读取、创建、更新、删除和导出分别定义权限，同时采用字段白名单和一致的审计记录。随机化对象标识只能降低枚举便利性，不能替代授权。复测时既要证明越权请求被拒绝，也要确认合法业务、不同 API 版本和相关功能没有被误伤。