OWASP Top 10:2025 榜首解析：失效的访问控制（Broken Access Control）的成因、攻击手法与完整防御清单-开发者社区

应用安全

【免费下载链接】Top10

Official OWASP Top 10 Document Repository

项目地址：https://gitcode.com/gh_mirrors/top/Top10

本文基于 OWASP Top 10 官方文档仓库中 2025 版意大利语 A01 章节（与英文原版、繁体中文版内容一致）撰写，系统讲解这一连续霸榜 #1 的 Web 应用安全风险的统计数据、八大典型成因、八条可落地的预防措施与三个经典攻击场景，并结合仓库中的方法论文档与数据提交样例，帮助开发、安全与 QA 人员建立可验证的访问控制防护体系。

一、背景：为什么它始终是第一

访问控制（Access Control）负责强制这样的策略：用户不能执行超出其预期权限的任何操作。一旦访问控制失效，通常会导致未经授权的信息泄露、全部数据被修改或销毁，或者执行超出用户权限范围的业务功能——这正是它长期高居 OWASP Top 10 榜首的根本原因。

2025 版官方文档给出的背景数据尤为严峻：

100%的受测应用被发现存在某种形式的访问控制失效；
在贡献数据集中，本类别的发生次数（Occurrences）最高，相关 CVE 数量位居第二；
值得重点关注的 CWE 包括CWE-200（向未授权主体暴露敏感信息）、CWE-201（通过已发送数据暴露敏感信息）、CWE-918（服务端请求伪造 SSRF）与CWE-352（跨站请求伪造 CSRF）。

需要特别说明的是，2025 版将SSRF（CWE-918）正式并入本类别。正如 2025 版引言中的映射图所示（图中以虚线标注），SSRF 从原来的独立条目被并入 Broken Access Control，这使本类别的边界从"纯访问控制缺陷"扩展到了"可被利用来突破信任边界的服务端请求类问题"。

二、2025 版评分表与数据要素解读

官方文档提供了完整的评分表，其统计口径由 What are Application Security Risks? 一章定义。A01:2025 的具体数据如下：

指标	数值
映射的 CWE 数量（CWEs Mapped）	40
最大发生率（Max Incidence Rate）	20.15%
平均发生率（Avg Incidence Rate）	3.74%
最大覆盖率（Max Coverage）	100.00%
平均覆盖率（Avg Coverage）	42.93%
平均加权可利用性（Avg Weighted Exploit）	7.04
平均加权影响（Avg Weighted Impact）	3.84
发生总数（Total Occurrences）	1,839,701
CVE 总数（Total CVEs）	32,654

这些指标的含义如下（依据仓库中 0x02_2025 文档的 Data Factors 一节）：

CWEs Mapped：Top 10 团队为类别映射的 CWE 数量。2025 版团队将每个类别最多映射 40 个 CWE，A01 正是达到 40 个上限的类别（全榜平均每类约 25 个，最低的 A03/A09 仅有 5 个）。之所以不采用 MITRE Top 25 那样的单条 CWE 列表，是因为并非所有 CWE 都存在于每种语言/框架中，且同一漏洞在不同组织可能登记为不同 CWE，多 CWE 分组更利于提升认知基线；
Incidence Rate（发生率）：某一组织在某一年度测试的应用中，发现存在该 CWE 的应用占比。计算时只看"应用是否含该弱点"，不看单个应用内出现多少次（频率），因为人工测试通常只记一次、自动化工具却会逐条记录；
Weighted Exploit / Weighted Impact：将映射到这些 CWE 的 CVE 所附 CVSSv2/v3 的 Exploit 与 Impact 子分数归一化到 10 分制后的平均值。仓库方法论说明：数据来自约 175k 条 NVD 中 CVE-CWE 映射记录（2021 版为 125k），其中 160k 条有 CVSSv2 分数、156k 条有 CVSSv3 分数、6k 条有 CVSSv4 分数；计算时按人群中的 CVSSv3 占比对两类分数加权取平均；
Coverage（覆盖率）：所有贡献组织对某一 CWE 测试的应用占其总测试应用的比例，覆盖率越高说明样本越具代表性、发生率越可信；
Total Occurrences / Total CVEs：映射到该类别的 CWE 在数据集中被发现的应用总数，以及 NVD 数据库中映射到这些 CWE 的 CVE 总数。

与 2021 版的纵向对比（数据来自仓库中 2021 版 A01 章节）：2021 版映射 34 个 CWE、平均发生率 3.81%、平均加权可利用性 6.92、平均加权影响 5.93、总发生次数 318,487、CVE 19,013。到 2025 版，CWE 映射数量从 34 扩至 40，总发生次数从约 31.8 万激增至约 184 万——这既反映了测试覆盖面的扩大，也说明访问控制缺陷在真实应用中的普遍程度并未缓解。

三、什么是失效的访问控制：八大典型漏洞形态

官方文档将常见的访问控制漏洞归纳为八类，这八类共同构成了"访问控制失效"的完整画像：

违反最小权限原则（deny by default）：访问本应只授予特定能力、角色或用户，却对任何人开放；
绕过访问控制检查：通过修改 URL（参数篡改 parameter tampering 或强制浏览 force browsing）、篡改应用内部状态或 HTML 页面，或使用能修改 API 请求的攻击工具；
不安全的直接对象引用（IDOR）：仅凭提供目标账户的唯一标识符，即可查看或编辑他人账户；
API 缺少访问控制：可访问的 API 对POST、PUT、DELETE等写操作缺少权限校验；
权限提升（Elevation of Privilege）：未登录即以用户身份操作，或取得超出已登录用户预期的高权限（如管理员权限）；
元数据操纵：重放或篡改 JSON Web Token（JWT）访问控制令牌、篡改 cookie 或隐藏字段以提权，或滥用 JWT 失效机制（例如注销后令牌仍可用）；
CORS 配置错误：允许来自未授权或不受信任来源的跨源 API 访问；
强制浏览：未认证用户猜测并访问认证页面，或普通用户猜测并访问特权页面。

四、如何预防：八条落地清单与测试要求

官方文档反复强调一个前提：访问控制只有在可信的服务端代码或 Serverless API 中实现才有效——因为只有在那里，攻击者才无法修改访问控制检查逻辑或其依赖的元数据。凡是在客户端（浏览器 JavaScript、隐藏字段）完成的访问控制，均可被轻易绕过。

在此基础上，预防措施共八条：

默认拒绝（Deny by default）：除明确标记为公共资源的路径外，一律拒绝访问；
一次实现、全应用复用：把访问控制机制做成统一的、可复用的组件，并在整个应用中重复使用，同时尽量少用 CORS（缩小跨源暴露面）；
模型层强制记录所有权：数据模型的访问控制应强制校验"记录归属"，而不是默认允许用户增删改查任意记录；
领域模型强制业务限额：应用特有的业务限制需求（如"用户只能查看自己订单"这类业务规则）由领域模型而非前端 UI 强制执行；
禁用目录列表、清理 Web 根目录：关闭 Web 服务器的 directory listing，并确保.git等文件元数据、备份文件不出现在 Web 根目录下；
记录失败并告警：记录访问控制失败事件，对重复失败等异常情况向管理员告警；
会话与令牌生命周期管理：有状态会话标识符必须在用户登出后由服务器端失效；无状态 JWT 应设置较短有效期，以缩小攻击者的可利用窗口；对长寿命 JWT，考虑引入 refresh token 并遵循 OAuth 标准的撤销流程；
采用成熟的声明式控制框架：使用经过验证的、提供简单声明式访问控制的工具包或模式，避免手写易错的判断逻辑。

此外，文档明确要求：开发人员与 QA 人员必须把功能性访问控制测试纳入单元测试与集成测试——访问控制不是"配一次就完事"的功能，而是需要随每次迭代持续回归验证的测试项。

五、攻击场景逐行拆解

场景 #1：参数篡改直取任意账户（IDOR / 未校验输入）

应用在访问账户信息的 SQL 调用中直接使用了未经验证的数据：

pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );

攻击者只需修改浏览器请求中的acct参数，即可指定任意账户编号：

https://example.com/app/accountInfo?acct=notmyacct

如果服务端没有校验"当前登录用户是否拥有该账户"，攻击者就能读取任意用户的账户信息。这同时涉及CWE-639（通过用户可控键绕过授权）与CWE-566（通过用户可控 SQL 主键绕过授权）两条映射 CWE。防御要点：绝不以客户端传入的标识符作为授权依据，必须校验记录所有权（对应预防第 3 条）。

场景 #2：强制浏览直接访问特权页面

攻击者强制浏览器访问特定 URL，例如：

https://example.com/app/getappInfo https://example.com/app/admin_getappInfo

访问管理页面本应要求管理员权限。若未认证用户能访问其中任一页面，即为缺陷；若非管理员用户能访问管理页面，同样是缺陷。这类问题对应CWE-425（直接请求/强制浏览），修复方式即"默认拒绝"加统一鉴权组件（对应预防第 1、2 条）。

场景 #3：前端控制被命令行轻易绕过

有些应用把所有访问控制都放在前端：浏览器中运行的 JavaScript 会阻止攻击者通过点击按钮进入https://example.com/app/admin_getappInfo，但这毫无意义——攻击者直接在命令行执行：

$ curl https://example.com/app/admin_getappInfo

即可绕过所有前端限制拿到页面内容。这正是文档强调"访问控制必须实现在可信服务端"的原因：凡是客户端能修改或绕过的检查，都不是访问控制。

六、映射的 40 个 CWE 全景列表

2025 版将本类别映射到 40 个 CWE，按缺陷性质可分为几大类，列表如下（编号与名称严格对应官方文档）：

路径与文件访问类：CWE-22对受限目录路径名限制不当（路径遍历）、CWE-23相对路径遍历、CWE-36绝对路径遍历、CWE-59文件访问前链接解析不当（跟随链接）、CWE-61跟随 UNIX 符号链接、CWE-65Windows 硬链接、CWE-424备用路径保护不当、CWE-425直接请求（强制浏览）。

敏感信息暴露类：CWE-200向未授权主体暴露敏感信息、CWE-201通过已发送数据暴露敏感信息、CWE-219在网站根目录下存储含敏感数据的文件、CWE-359向未授权主体暴露私人个人信息、CWE-497向未授权控制范围暴露敏感系统信息、CWE-538将敏感信息写入外部可访问文件或目录、CWE-540源代码中包含敏感信息、CWE-548通过目录列表暴露信息、CWE-552文件或目录可被外部方访问、CWE-615源代码注释中包含敏感信息、CWE-922敏感信息存储不安全。

权限与所有权管理类：CWE-276默认权限错误、CWE-281权限保留不当、CWE-282所有权管理不当、CWE-283未验证所有权、CWE-284访问控制不当、CWE-285授权不当、CWE-732关键资源权限分配错误、CWE-862缺少授权、CWE-863授权错误。

绕过与提权类：CWE-352跨站请求伪造（CSRF）、CWE-566通过用户可控 SQL 主键绕过授权、CWE-601网址重定向到不可信站点（开放重定向）、CWE-639通过用户可控键绕过授权、CWE-749暴露危险方法或函数、CWE-918服务端请求伪造（SSRF）。

资源与环境类：CWE-377不安全的临时文件、CWE-379在权限不安全的目录中创建临时文件、CWE-402将私有资源传输到新的范围（资源泄漏）、CWE-441非预期代理或中介（混淆代理）、CWE-668将资源暴露到错误范围、CWE-1275敏感 Cookie 的SameSite属性设置不当。

可以看到，该类别从"直接的越权与绕过"一路延伸到"错误范围内暴露资源""敏感数据置于可访问位置""临时文件权限"等外围问题，覆盖面远比"用户 A 访问用户 B 数据"这一狭义理解更广。这也解释了为什么它拥有全榜最多的 40 个映射 CWE。

七、从数据到榜单：A01 的数据是如何统计的

要真正理解"1,839,701 次发生"这个数字，需要了解 2025 版的数据收集与分析流程。仓库中的 Data 目录说明给出了完整机制：

数据来源：安全厂商、咨询公司、漏洞赏金平台以及企业/组织贡献，覆盖 2021～2024 年时间段，提交截止至 2025 年 7 月 31 日；
测试类型：区分 Human assisted Tooling（HaT，人辅工具）与 Tooling assisted Humans（TaH，工具辅人）两类，两种类型建议拆分为两个独立数据集提交；
提交格式：支持 CSV / Excel / JSON，每份数据集需声明贡献者、测试应用总数、各 CWE 命中的应用数、时间周期、测试类型、主要语言、地理区域、行业等元数据。

仓库中的 sample-data-submission.csv 给出了提交样例的核心结构：

NumberofAppsTested,CWE,NumberofAppsPer,TimePeriod,ContributorName,ContributorContactEmail,TypeofTesting,PrimaryLanguage,Region,Industry,Retest 100,20,53,2021,Name,Email,TAH,.NET,North America,Retail,F 100,425,5,2021,Name,Email,TAH,.NET,North America,Retail,F

即：某组织对 100 个应用做了测试，其中 53 个应用存在 CWE-20、5 个应用存在 CWE-425。相应的 JSON 样例以contributions结构组织同样的信息。每个 CWE 的"发生次数"= 命中的应用数，而非漏洞实例数——这正是前文强调的"只看流行率、不看频率"的统计口径。

类别排序则依据 0x02_2025 文档给出的风险评分公式：

(Max Incidence Rate % × 1000) + (Max Coverage % × 100) + (Avg Exploit × 10) + (Avg Impact × 20) + (Sum Occurrences / 10000) = Risk Score

10 个类别中由数据驱动排名 8 个，其余 2 个由社区调查投票选出（以弥补数据只能反映"过去已可测试的弱点"这一固有局限）。A01 的评分在本轮全部候选类别中最高（621.60 分），最终稳居第一。此外需注意：2025 版数据分析涉及约 589 个 CWE（2021 版约 400 个），团队花费数月完成了 CWE 分组归类，并将单类别 CWE 数量上限设为 40——A01 正是触及上限的类别。

八、延伸阅读

原文档末尾还引用了多份官方参考资料，可作为深入学习的下一站（按原文档指引）：OWASP Proactive Controls 的 "C1: Implement Access Control"、OWASP ASVS 5.0 的 "V8 Authorization" 章节、OWASP Web Security Testing Guide 的 Authorization Testing 部分、OWASP Authorization Cheat Sheet、PortSwigger 关于 CORS 配置错误利用的分析，以及 OAuth 规范中撤销访问的标准做法。

在本仓库内可继续研读的配套资料包括：

2025 版英文原版 A01 章节与 2025 版繁体中文 A01 章节，便于对照原文表述；
2025 版引言（What's changed），了解 SSRF 并入本类别及其他类别的调整逻辑；
应用安全风险定义与评分方法论，掌握全部数据要素口径；
2021 版 A01 章节，纵向对比 34 → 40 个 CWE 的类别演进；
数据收集计划与提交指南及 CSV 样例、JSON 样例，若组织希望参与下轮数据贡献可参考。

总结：失效的访问控制之所以连续登顶，根源在于它横跨了架构设计（默认拒绝、记录所有权）、运行时防护（统一鉴权组件、会话/JWT 生命周期、速率限制）、基础设施（目录列表、CORS）与质量保障（单元/集成测试）四个层面，任何一个环节失守都会产生可利用的越权路径。以本文的八类形态自检、以八条预防清单落地、以三个攻击场景做回归测试，是应对这一头号风险的完整闭环。