在 OWASP Top 10:2025 里，Broken Access Control（访问控制失效） 仍然排在 A01，也就是第 1 位。它的意思很直接：系统没有正确限制“谁能访问什么、谁能执行什么操作”，结果就是用户能看到、修改、删除本不属于自己的数据，甚至越权拿到管理员能力。OWASP 给出的 2025 数据里，这一类问题覆盖了 100% 被测试应用，而且总出现次数非常高，说明它不是“高级漏洞”，而是最常见、最容易被遗漏的基础性问题。
来源：OWASP A01:2025 Broken Access Control

你可以把它和“认证”区分开来理解：
认证（Authentication） 是“你是谁”，授权/访问控制（Authorization / Access Control） 是“你被允许做什么”。很多系统登录做得还行，但授权做得很松，这就会出现“普通用户登录后直接改 URL 看别人订单”“前端隐藏了管理按钮，但接口没拦截”“把 JWT 里的 role 改成 admin 就真能生效”这类问题。

常见表现

• IDOR / 越权访问对象：把 /orders/1001 改成 /orders/1002 就能看别人的订单。
• 功能级越权：普通用户能调用本该只有管理员可用的 POST/PUT/DELETE 接口。
• 前端做了限制，后端没做校验：按钮虽然隐藏，但直接抓包重放请求仍然成功。
• 权限提升：未登录用户访问已登录页面，或普通用户进入管理员页面。
• Token / Cookie / Hidden Field 被篡改：服务端错误地信任客户端传来的角色、权限、状态。
• CORS 配置错误：把不可信来源也放进允许列表，导致跨站调用敏感 API。
• Force Browsing：猜 URL 就能访问受限资源、备份文件、目录列表或 .git 等敏感内容。

为什么它危险

• 它直接破坏“业务边界”，不是只泄露一条数据，而是可能整库查看、批量修改、批量删除。
• 它常常绕过的是“业务规则”而不是技术边界，所以影响往往比单点漏洞更大。
• API、前后端分离、微服务、移动端特别容易放大这个问题，因为请求面更多、角色更多、资源更多。

OWASP 官方举的典型攻击思路

• 修改请求参数里的账户 ID，访问别人的账户信息。
• 直接访问管理接口 URL，看后端是否真的做了管理员校验。
• 如果权限检查只写在浏览器里的 JavaScript，攻击者完全可以绕过前端，直接 curl 调接口。

怎么防

• 采用 deny by default：除公开资源外，默认拒绝访问。
• 把权限校验放在服务端，不要信任前端、隐藏字段、JWT 中未经验证的声明。
• 统一做授权逻辑：不要每个接口自己拼一套判断。
• 校验“资源归属”而不只是“是否登录”：例如用户只能读写自己的订单、自己的文件。
• 对高风险操作加业务约束：金额上限、审批流、状态机顺序、频率限制。
• 正确处理会话和 token：登出后失效；JWT 短生命周期；需要时支持吊销。
• 记录并告警授权失败，防止批量探测。
• 把授权测试写进单元测试和集成测试，最好做“角色 × 功能 × 数据范围”的权限矩阵测试。
  补充参考：OWASP Authorization Testing Automation Cheat Sheet

如果你是从开发角度记忆它，可以用一句话概括：
Broken Access Control = 后端没有持续、统一、按资源归属和角色边界去验证“这个用户是否真的能做这件事”。