OWASP Top 10 2025 总览与分析

这份笔记适合怎么用

• 如果你是开发者：先看“怎么理解这份榜单”，再看每一项的“开发/排查重点”。
• 如果你是安全测试人员：重点看每一项的“常见表现”和“检查点”。
• 如果你是做安全治理：重点看“2025 版变化”和“落地建议”。

一、OWASP Top 10 2025 是什么

OWASP Top 10 是面向 Web 应用安全风险的高优先级清单。
2025 版是第 8 次发布，官方说明它依旧是“数据驱动，但不盲从数据”的榜单：一部分来自大规模测试数据，一部分来自社区调查，用来补足那些“现实里很重要、但不容易被自动化工具统计出来”的风险。

我对它的理解是：

• 它不是漏洞库，而是“风险类别榜单”。
• 它不要求你背 10 个名词，而是要求你识别 10 类最常见的失守方式。
• 它越来越强调“根因”而不是“表象”。

比如：

• 以前常说“敏感信息泄露”，现在更追问它为什么泄露，是访问控制失效、加密失败，还是日志/异常处理问题。
• 以前常把问题看成单点漏洞，现在更强调系统、配置、供应链、设计、流程这些成因。

二、2025 版最值得注意的变化

1. 新增或重构的类别

• A03 Software Supply Chain Failures：把 2021 版“易受攻击/过时组件”扩展成更大的“软件供应链失败”。
• A10 Mishandling of Exceptional Conditions：新增“异常条件处理不当”，强调错误处理、fail-open、资源/状态异常、逻辑异常。
• SSRF 被并入 A01 Broken Access Control，体现它很多时候本质上是信任边界和访问边界失守。

2. 排名变化明显

• A02 Security Misconfiguration 从 2021 的第 5 名升到 2025 的第 2 名。
• A03 Software Supply Chain Failures 升得很高，说明现代软件交付链已经成为核心攻击面。
• A04 Cryptographic Failures、A05 Injection、A06 Insecure Design 相对后移，但绝不代表不重要。

3. 官方更强调“现代工程现实”

2025 版非常明显地在回应这些现实问题：

• 云原生与高度可配置系统越来越多。
• 依赖、构建、制品、CI/CD 已经成为攻击面。
• 单纯靠编码阶段补洞不够，必须把安全前移到设计、需求、流程和供应链。
• 可观测性、告警、异常恢复已经不是“运维问题”，而是应用安全问题。

三、2025 Top 10 排名速览

四、怎么理解这份榜单

1. 前三名本质上都在讲“信任边界”

• A01 关注“谁可以做什么”。
• A02 关注“系统默认边界有没有收紧”。
• A03 关注“你信任的软件和交付链值不值得信任”。

换句话说，现代安全问题已经不只是“输入是否合法”，而是“系统到底把谁当自己人、把什么当可信来源”。

2. 2025 版比以前更偏“系统性风险”

旧思路更像：

• SQL 注入
• 弱密码
• 明文传输

新思路更像：

• 你的系统有没有统一的授权模型
• 你的安全配置是不是可重复、可审计、可自动化
• 你的构建链、依赖链、更新链是不是可追踪、可验证、可回滚

3. 很多风险之间会相互放大

典型组合：

• A02 配置错误 暴露接口或目录，进一步导致 A01 越权
• A10 异常处理失效 没有 fail-closed，进一步造成 A01 或 A07
• A09 日志告警失效 让 A03 或 A08 的入侵长期不被发现
• A06 设计缺陷 往往是 A01/A07/A10 的上游根因

所以不要把 Top 10 当成 10 个孤立桶，它更像 10 种常见失守方式。

五、10 个风险的中文理解与排查重点

A01 Broken Access Control

核心含义

访问控制的本质是：系统必须持续判断“这个用户是否真的能对这个资源做这件事”。
一旦这个判断只做了前端限制、只判断是否登录、或没有校验资源归属，就会失守。

常见表现

• 通过修改 URL、参数、对象 ID 查看或修改他人的数据
• 普通用户可以访问管理员接口
• 前端隐藏了按钮，但后端接口仍可直接调用
• JWT、Cookie、隐藏字段被篡改后产生越权
• CORS 配置过宽导致不可信来源可调用敏感 API
• 可通过猜测 URL 直接访问受限页面、备份文件、目录列表

开发/排查重点

• 所有授权判断必须落在服务端
• 默认拒绝，公开资源以外一律显式放行
• 不只校验“是否登录”，还要校验“是否有权访问该资源”
• 把授权逻辑做成统一组件，不要每个接口各写一套
• 对高风险接口做速率限制、失败日志和告警

A02 Security Misconfiguration

核心含义

不是代码一定写错了，而是系统、框架、服务、云资源、头部策略、权限或错误处理没有被安全地配置。

常见表现

• 默认账号、默认密码未修改
• 多余端口、页面、测试框架、示例应用仍暴露
• 目录浏览未关闭
• 安全头缺失或值不安全
• 云存储、云权限、ACL 过宽
• 报错把堆栈、版本、内部细节直接返回给用户
• 升级后新安全特性没开启，或为了兼容保留旧配置

开发/排查重点

• 建立可重复的加固基线，开发/测试/生产环境一致
• 最小化安装与最小暴露面
• 自动化校验配置，不要只靠人工检查
• 云权限、对象存储、容器/安全组单独审计
• 用身份联邦、短期凭证、角色机制替代静态密钥

A03 Software Supply Chain Failures

核心含义

风险不再只是“依赖有漏洞”，而是“从依赖、构建、仓库、CI/CD、IDE 到更新发布的整条供应链，都可能被投毒、篡改、失管或长期暴露”。

常见表现

• 不清楚项目到底依赖了哪些直接/间接组件
• 组件过时、无人维护、有已知漏洞但长期不升级
• CI/CD 权限过大，缺少职责分离
• 代码仓库、制品仓库、容器仓库缺少完整性保护
• 从不可信来源下载包、镜像、脚本或构建插件
• 开发工具链本身长期不更新
• 供应链变更无记录、无追踪、无回滚策略

开发/排查重点

• 建立并持续维护 SBOM
• 跟踪直接依赖和传递依赖
• 订阅 CVE/NVD/OSV 等漏洞情报
• 只从可信源拉取依赖，优先校验签名
• 对代码仓库、CI/CD、构建机、制品做 MFA、最小权限、审计与防篡改
• 发布采用分阶段/金丝雀，而不是一次性全量推送

A04 Cryptographic Failures

核心含义

问题不只是“没加密”，还包括：算法弱、密钥差、随机数弱、模式错误、证书验证错误、密钥管理失控。

常见表现

• 敏感数据传输未强制 TLS
• 敏感数据静态存储未加密
• 使用过时算法、弱哈希、弱随机数
• IV 重用、ECB 模式、错误的认证加密选择
• 密钥写进代码仓库或配置文件
• 密钥长期不轮换、默认密钥复用
• 证书链、主机名校验不严

开发/排查重点

• 先做数据分级，明确哪些数据必须重点保护
• 传输中和静态存储的敏感数据都要加密
• 优先使用成熟库与平台能力，不要自造轮子
• 密钥放入 HSM 或云 KMS，建立轮换策略
• 强制 TLS 1.2+、HSTS、强密码套件
• 密码存储使用 Argon2、scrypt、PBKDF2 等自适应哈希

A05 Injection

核心含义

只要不可信输入进入解释器，并被当成“命令的一部分”执行，就属于注入问题。
对象可以是数据库、操作系统、模板引擎、LDAP、表达式引擎等。

常见表现

• SQL/NoSQL 注入
• OS 命令注入
• LDAP/EL/OGNL 注入
• ORM/HQL 拼接查询
• 存在大量字符串拼接式动态查询
• 输入校验、过滤、转义依赖前端或不做上下文区分

开发/排查重点

• 数据与命令必须分离
• 优先使用参数化接口、安全 API 或 ORM
• 服务端白名单校验输入
• 对剩余的动态结构做针对解释器的上下文转义
• 在 CI/CD 中加入 SAST、DAST、IAST、Fuzzing
• 对所有输入面做覆盖：参数、Header、Cookie、JSON、XML、SOAP

A06 Insecure Design

核心含义

这是“控制设计缺失或无效”，不是简单的编码失误。
如果业务流程、权限模型、失败状态、租户隔离、交易边界在设计阶段就没想清楚，后面实现再规范也可能只是把坏设计写得更稳定。

常见表现

• 找回密码流程设计本身不安全
• 多租户隔离只靠表字段，没有架构层隔离
• 业务状态机允许跳步、重复消费、回滚失序
• 关键流程没有威胁建模
• 需求文档没有安全要求，用户故事没有误用场景

开发/排查重点

• 在需求与设计阶段引入安全活动，而不是只在编码后补洞
• 对认证、授权、业务逻辑、关键数据流做威胁建模
• 把“正常流”和“失败流”都设计清楚
• 建立安全设计模式库和安全组件铺装路
• 用单元测试和集成测试验证关键流与误用流

A07 Authentication Failures

核心含义

系统把错误的人识别成了正确的人，或者让攻击者太容易伪造、复用、猜解、接管身份。

常见表现

• 允许撞库、密码喷洒、暴力破解
• 使用默认口令、弱口令、泄露口令
• 找回密码流程脆弱
• 缺少 MFA，或 MFA 回退机制太弱
• Session ID 放在 URL 或可被前端轻易读取的位置
• 登录后不更换 Session ID
• 注销或空闲后 Token/Session 未正确失效
• JWT 的 aud、iss、scope 校验不严

开发/排查重点

• 优先启用 MFA
• 禁止默认凭证，校验弱密码与泄露密码
• 做账户枚举防护，统一错误提示
• 对登录失败做节流、延迟、告警
• 登录后重新签发高熵 Session ID
• 统一会话生命周期：登录、注销、空闲超时、绝对超时
• 尽量使用成熟身份系统，不自己实现整套认证体系

A08 Software or Data Integrity Failures

核心含义

这里强调的是：你在“完整性还没验证”的情况下就开始信任代码、更新、模块或数据。
它和 A03 的区别是，A03 更偏“整条供应链治理”，A08 更偏“对象级信任与完整性验证”。

常见表现

• 从不可信 CDN、仓库、插件源加载功能
• 自动更新包未校验签名或来源
• 反序列化不可信数据
• CI/CD 拉取外部制品不验签
• 代码/配置修改缺少审查流程

开发/排查重点

• 对软件包、更新包、数据对象做签名或完整性校验
• 依赖只来自可信仓库，必要时使用内部白名单仓库
• 强化代码与配置变更审查
• CI/CD 做隔离、权限控制和制品完整性验证
• 对序列化对象增加防篡改校验，避免直接信任客户端数据

A09 Security Logging and Alerting Failures

核心含义

风险不是“没有日志”这么简单，而是：系统在被攻击、被试探、被滥用时，不能被及时、正确、可操作地发现。

常见表现

• 只记录成功登录，不记录失败登录
• 日志无用户上下文，无法溯源
• 告警阈值、升级流程、值班机制缺失
• 日志只保存在本地，可被删改
• DAST/渗透测试都打不出告警
• 记录了敏感信息，或日志本身可被注入污染
• 异常发生了，但系统既没记，也没报
• 误报太多，真正的告警被淹没

开发/排查重点

• 登录、授权失败、服务端校验失败、关键交易都要可审计
• 日志要可被 SIEM/SOC 消费
• 对日志做防篡改与完整性保护
• 告警必须有可执行 playbook，不是“发出来就算完”
• 控制误报，保证真正攻击能被看到
• 敏感数据不要写日志，日志输出要做安全编码

A10 Mishandling of Exceptional Conditions

核心含义

系统面对缺参、空指针、资源不足、网络异常、权限异常、时序异常、状态异常时，没能在“发生点”被正确处理，最后进入不可预测状态，甚至 fail-open。

常见表现

• 只在高层统一 try/catch，底层失败原因被吞掉
• 事务失败后未完整回滚
• 异常时默认放行、默认继续执行、默认返回成功
• 缺少限流、配额、节流，导致资源异常可被放大成 DoS
• 异常没有监控、没有告警、没有恢复策略
• 输入验证缺失导致异常状态被攻击者持续触发

开发/排查重点

• 在异常发生点捕获并做有意义的处理
• 关键事务失败必须 fail-closed，并完整回滚
• 建立全局异常处理器，但不能替代局部正确处理
• 对重复错误、异常峰值建立监控和告警
• 加限流、资源配额、熔断、超时、重试策略
• 统一异常处理方式，不要一个系统里多套风格并存

六、容易混淆的几个边界

A03 vs A08

• A03 更像“供应链治理失效”
• A08 更像“对象完整性验证失效”

前者关注依赖、构建、仓库、CI/CD、发布链。
后者关注更新包、模块、序列化对象、外部脚本、数据对象是否被当成可信内容直接执行或消费。

A01 vs A07

• A07 是“你是谁”
• A01 是“你能做什么”

很多系统认证做得不错，但授权做得很弱，所以登录以后仍然能越权。

A02 vs A10

• A02 是安全基线没有配好
• A10 是异常、错误、故障出现时没有被安全地处理

一个偏“部署与运行基线”，一个偏“异常流与失败流设计/实现”。

A06 vs 其他所有项

A06 很像上游根因。
很多访问控制、认证、异常处理问题，表面看是实现错误，根上其实是设计阶段没定义好安全约束和失败状态。

七、如果你要把 Top 10 用到实际项目，建议这样落地

对开发团队

先抓这 5 件事：

1. 授权统一收口，按资源归属校验。
2. 配置基线自动化，尤其是云权限、对象存储、安全头、默认账户。
3. 建立 SBOM、依赖监控、CI/CD 加固。
4. 所有认证链路接入 MFA、会话治理和弱口令/泄露口令检测。
5. 打通日志、告警、异常处理和回滚机制。

对测试团队

优先做这 5 类检查：

1. 越权测试：横向越权、纵向越权、对象级越权、功能级越权。
2. 配置测试：目录浏览、默认账号、安全头、错误信息、云权限。
3. 供应链测试：依赖版本、签名、来源、CI/CD 权限、制品可信度。
4. 认证测试：撞库、爆破、枚举、找回密码、Session 生命周期、JWT 校验。
5. 异常流测试：缺参、超长、边界值、并发、重复提交、超时、资源耗尽、回滚。

对治理或安全负责人

不要只做“漏洞修复率”指标，还要看：

• 权限模型是否统一
• 配置是否基线化、自动化
• 依赖与制品是否可追踪
• 关键流程是否做威胁建模
• 告警是否真的能触发响应
• 异常交易是否真的能回滚与 fail-closed

八、我的整体判断

2025 版的核心信号是：

• 安全问题正在从“单点漏洞”转向“工程系统失控”。
• 现代应用真正危险的地方，往往不是某一行代码，而是默认信任、缺少验证、缺少治理、缺少失败处理。
• 如果一个团队只会修 SQL 注入和 XSS，但没有统一授权、没有供应链治理、没有告警和异常恢复能力，那么它仍然处在高风险状态。

一句话总结：

OWASP Top 10 2025 不只是“十大漏洞”，更像“现代应用最常见的十种安全失守模式”。

参考链接

• 官方主页：https://owasp.org/Top10/2025/
• 介绍页：https://owasp.org/Top10/2025/0x00_2025-Introduction/
• A01：https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
• A02：https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/
• A03：https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/
• A04：https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/
• A05：https://owasp.org/Top10/2025/A05_2025-Injection/
• A06：https://owasp.org/Top10/2025/A06_2025-Insecure_Design/
• A07：https://owasp.org/Top10/2025/A07_2025-Authentication_Failures/
• A08：https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/
• A09：https://owasp.org/Top10/2025/A09_2025-Security_Logging_and_Alerting_Failures/
• A10：https://owasp.org/Top10/2025/A10_2025-Mishandling_of_Exceptional_Conditions/