OWASP top10 2025详解

OWASP Top 10:2025 十大 Web 应用安全风险深度解析与案例分析

2025的排名对比2023新增了几个风险类别，还有对以前的类型进行了整合与重命名

失效的访问控制仍是top1，说明越权访问、权限校验缺失等问题依旧是 Web 应用面临的重要风险。

排名	英文名称	中文名称
A01	Broken Access Control	失效的访问控制
A02	Security Misconfiguration	安全配置错误
A03	Software Supply Chain Failures	软件供应链失效
A04	Cryptographic Failures	加密机制失效
A05	Injection	注入
A06	Insecure Design	不安全设计
A07	Authentication Failures	认证失效
A08	Software or Data Integrity Failures	软件或数据完整性失效
A09	Security Logging & Alerting Failures	安全日志记录和告警失效
A10	Mishandling of Exceptional Conditions	异常条件处理不当

A01:2025 — 失效的访问控制（Broken Access Control）

1. 漏洞原理

访问控制是指系统根据用户身份、角色和权限，决定用户能够访问哪些资源以及执行哪些操作的安全机制。例如，普通用户只能查看自己的个人资料，管理员则可以管理平台内的用户信息。访问控制失效后攻击者可以通过修改请求数据，抓包来实现越权获得管理员权限数据，常见表现包括水平越权、垂直越权以及未授权访问。水平越权是普通用户访问其他同级用户的数据；垂直越权是普通用户获得管理员权限；

假设某电商网站提供订单查询接口：

GET /api/orders/10001

用户 A 登录后可以正常查询自己的订单，订单编号为 10001。

但是，该系统的后端程序只根据订单编号查询数据库，没有验证订单是否属于当前登录用户。

当用户 A 将请求中的订单编号修改为 10002 时，服务器仍然返回了该订单的详细信息，而实际上这笔订单属于用户 B。

这说明系统虽然进行了登录身份验证，却没有执行订单归属权检查，导致水平越权漏洞。

如果类似问题发生在后台管理接口中，还可能允许普通用户修改其他用户信息，甚至执行管理员操作。

2.防护措施

系统应遵循最小权限原则，并在服务器端实施统一的访问控制。每次访问订单、文件、账户等资源时，都应检查当前用户是否具有相应权限。

例如，查询订单时不仅需要验证订单编号，还需要检查数据库中记录的用户 ID 是否与当前登录用户一致。

此外，还应默认拒绝未经明确授权的访问，避免将权限判断完全交给前端页面。对于异常权限访问，应记录日志并设置告警机制。

 

2.2 A02:2025 — 安全配置错误（Security Misconfiguration）

1. 漏洞原理

安全配置错误是指服务器、数据库、云服务、应用框架或网络设备的配置不符合安全要求，导致攻击者能够利用错误配置访问系统资源。

与代码漏洞不同，配置错误往往不需要复杂的程序缺陷。例如，系统可能已经采用安全的开发框架，但由于管理员保留默认密码，攻击者仍然能够直接登录后台。

常见的配置问题包括：启用不必要的服务端口、保留测试页面、默认密码未修改、云存储权限过于宽松、调试模式没有关闭，以及向用户暴露详细的系统报错信息。

2. 具体案例：云存储权限设置错误

假设某企业将员工资料、客户合同和业务报表存储在云对象存储服务中。

管理员在创建存储桶时，为方便员工访问，将存储桶权限设置为允许互联网匿名读取。

随后，企业在网站上使用了其中一个文件的公开链接。攻击者发现相关存储配置后，进一步识别出其他可以匿名访问的敏感文件。

虽然企业的登录系统、数据库和程序代码都没有明显漏洞，但由于云存储权限配置错误，攻击者仍然能够获取大量内部资料。

类似问题也可能出现在服务器目录浏览功能中。如果服务器允许列出某个目录内的文件，攻击者可能发现备份文件、配置文件或者历史版本代码。

3. 安全危害

安全配置错误可能导致敏感文件泄露、服务器被非法登录、内部网络暴露，严重情况下还可能成为攻击者进一步入侵企业系统的入口。

4. 防护措施

企业应建立统一的安全配置基线，在系统部署时自动检查关键配置，包括账户权限、端口开放范围、云存储访问策略以及调试功能状态。

生产环境应关闭无关服务，删除测试程序和默认账户，并采用最小权限原则管理云平台访问权限。

同时，可以使用配置扫描工具、基础设施即代码（IaC）审查等方法，定期检查生产环境与安全基线之间的差异，减少人为配置错误。

OWASP Top 10:2025

 

2.3 A03:2025 — 软件供应链失效（Software Supply Chain Failures）

1. 漏洞原理

软件供应链是指软件从设计、开发、构建、测试到发布的完整过程，包括开发工具、开源组件、第三方依赖、代码仓库以及自动化部署平台等。

现代 Web 系统往往不是完全由开发人员独立编写，而是依赖大量开源框架和第三方软件包。因此，即使企业自己的代码没有漏洞，也可能因为引用的组件存在安全问题而受到攻击。

供应链攻击还可能发生在软件更新阶段。攻击者通过污染第三方软件包、窃取开发者凭据或者控制构建环境，将恶意代码混入原本可信的软件中。

2. 具体案例：第三方软件包被植入恶意代码

假设某企业使用 Node.js 开发业务管理系统，项目通过 npm 安装一个用于处理日期格式的第三方组件。

攻击者入侵了该组件维护者的账户，并发布了包含恶意代码的新版本。

企业开发人员没有对更新进行安全检查，自动化构建系统直接安装了这一版本。恶意代码在安装或执行过程中读取构建环境中的敏感信息，例如访问令牌，并将其发送到攻击者控制的服务器。

此时，企业真正受到攻击的入口不是自己编写的业务接口，而是被信任的第三方依赖。

现实中，OWASP 2025 官方文档提到了 2025 年的 Shai-Hulud npm 供应链攻击，说明恶意软件包还可能利用被窃取的发布凭据继续感染其他软件包，形成连锁传播。

3. 安全危害

供应链失效可能影响多个系统，造成源代码泄露、凭据被窃取、服务器被控制，甚至通过软件更新机制将恶意代码分发给大量用户。

4. 防护措施

企业应建立软件物料清单（SBOM），记录软件使用的直接依赖和间接依赖，并持续关注 CVE、NVD 等漏洞信息来源。

软件组件应优先从可信仓库获取，重要制品应验证数字签名及来源。构建和发布环节需要启用多因素认证、最小权限控制、代码审查及发布审批机制。

同时，应对自动更新实施版本控制和分阶段发布。发现供应链异常时，能够迅速停止部署并回滚到经过验证的安全版本。

OWASP Top 10:2025

 

2.4 A04:2025 — 加密机制失效（Cryptographic Failures）

1. 漏洞原理

加密机制是保护数据机密性、完整性和安全传输的重要技术。加密机制失效并不一定意味着攻击者破解了先进的加密算法，更多情况下是系统没有正确使用密码学技术。

典型问题包括使用过时的加密算法、明文传输敏感数据、密码采用弱哈希方式存储、密钥直接写入源代码，以及随机数生成机制不安全等。

例如，MD5 和 SHA-1 已经不适合直接用于密码存储。即使密码经过一次 MD5 运算，攻击者在获得哈希值后，仍可能利用字典和高速计算工具恢复部分原始密码。

2. 具体案例：用户密码使用 MD5 存储

假设某论坛拥有数十万用户，开发人员为了简化系统开发，将用户密码转换为 MD5 哈希值后保存在数据库中。

某天，论坛因其他漏洞导致用户数据库泄露。

攻击者虽然没有直接获得明文密码，但可以使用常见密码字典进行离线猜测，通过计算候选密码的 MD5 值并与泄露数据比较，找出部分用户使用的密码。

如果用户在电子邮箱、电商网站和其他平台使用相同密码，还可能引发进一步的账户被盗事件。

这说明仅仅对密码进行哈希处理，并不意味着密码存储方式已经足够安全。

3. 安全危害

加密机制失效可能造成密码泄露、通信内容被窃听、身份凭据被盗、敏感业务数据外泄，进而引发账户接管和财产损失。

4. 防护措施

网站应使用 HTTPS 和安全的 TLS 协议保护网络通信。对于数据库中的敏感信息，应根据数据分类采取适当的静态加密措施。

用户密码应采用 Argon2id、scrypt 等适合密码存储的算法，通过随机盐值和合理的计算成本提高离线破解难度，而不是简单地使用 MD5 或 SHA-256。

对于加密密钥，应采用专门的密钥管理服务或硬件安全模块进行保护，建立密钥轮换与访问审计机制。

需要区分的是：密码通常应使用单向密码哈希保存，而不是可逆加密。

OWASP Top 10:2025

 

2.5 A05:2025 — 注入（Injection）

1. 漏洞原理

注入漏洞是 Web 应用中最经典的安全问题之一，其核心原因是程序没有正确区分用户输入的数据和系统执行的指令。

当用户输入被直接拼接进 SQL 查询、操作系统命令或其他解释器表达式时，攻击者就可能通过构造特殊输入，改变程序原本的执行逻辑。

常见注入漏洞包括 SQL 注入、NoSQL 注入、命令注入、LDAP 注入等。跨站脚本攻击（XSS）也被纳入 OWASP 2025 的注入风险类别。

2. 具体案例：SQL 注入绕过查询条件

假设某网站使用以下 Python 代码查询用户：

sql = (    "SELECT * FROM users WHERE username='"    + username + "'")

 

这段代码直接把用户输入的 username 拼接到 SQL 语句中。

在正常情况下，用户输入 zhangsan，系统会查询该用户的记录。

但是，如果恶意输入包含 SQL 特殊字符及逻辑表达式，数据库可能将其中一部分内容理解为 SQL 指令，而不是普通用户名。

例如，在缺少安全处理的情况下，某些构造可能使原本只查询一个用户的语句变成返回多条记录的查询，从而破坏程序预期的访问限制。

3. 安全危害

SQL 注入可能导致数据库敏感信息泄露、数据被非法修改或删除。在特定数据库配置和权限条件下，还可能进一步影响服务器安全。

命令注入则可能让攻击者借助程序调用系统命令，执行未经授权的操作。

XSS 主要影响浏览器端，攻击者可能借此在受害者页面上下文中执行恶意脚本，窃取可访问的信息或冒用用户操作。

4. 防护措施

防止 SQL 注入最有效的方式之一是使用参数化查询，将 SQL 指令和用户输入分离。

例如：

sql = "SELECT * FROM users WHERE username = ?"cursor.execute(sql, (username,))

 

这样，用户输入会被作为参数值处理，而不再直接改变 SQL 语句结构。

此外，应采用服务端输入验证、上下文相关的输出编码以及最小数据库权限控制。对于 XSS，需要根据 HTML、属性、URL 和 JavaScript 等不同输出上下文进行针对性处理。

企业还可以通过静态应用安全测试（SAST）、动态应用安全测试（DAST）和代码审计，在系统上线前识别潜在注入风险。

OWASP Top 10:2025

 

2.6 A06:2025 — 不安全设计（Insecure Design）

1. 漏洞原理

不安全设计是指应用系统在需求分析、架构设计或业务流程设计阶段，没有充分考虑潜在安全威胁，从而形成系统性的安全缺陷。

这一类别与代码实现错误存在明显区别。

代码实现错误通常可以通过修改程序逻辑、修复函数或者增加校验解决，而不安全设计往往意味着系统在最初设计时就缺少必要的安全控制。

例如，某购物网站没有限制优惠券的使用次数，即使所有程序代码都按照设计正常运行，攻击者仍可能通过重复提交订单来滥用优惠券。

因此，安全设计不仅要求程序运行正确，还需要考虑系统是否可能被恶意使用。

2. 具体案例：优惠券重复使用

假设某电商平台推出一张价值 100 元的优惠券，业务规定每名用户只能使用一次。

但是，开发人员仅在用户进入支付页面时检查优惠券是否已经使用，并未设计原子性的优惠券核销机制。

攻击者在极短时间内同时提交多个订单。这些订单在查询优惠券状态时，都发现优惠券尚未被使用，因此全部通过校验。

最终，一张优惠券被重复抵扣多次，造成平台经济损失。

该问题属于典型的业务逻辑和并发控制设计缺陷。

3. 安全危害

不安全设计可能导致业务规则被绕过、平台资源被滥用、交易异常甚至经济损失。某些漏洞无法通过普通漏洞扫描工具发现，需要结合具体业务流程进行测试。

4. 防护措施

企业应在需求分析和系统设计阶段开展威胁建模，识别攻击者可能利用的业务路径。

对于资金交易、优惠券核销和预约资源等关键流程，应采用数据库事务、原子更新、唯一约束和必要的并发控制。

同时，安全测试不仅要检查正常业务流程，还应验证重复请求、异常顺序、并发操作以及恶意业务行为。

OWASP Top 10:2025

 

2.7 A07:2025 — 认证失效（Authentication Failures）

1. 漏洞原理

身份认证是系统判断用户是否具有合法身份的过程，通常通过密码、短信验证码、多因素认证或者身份令牌实现。

认证失效是指系统的认证机制存在缺陷，使攻击者能够冒用他人身份或者绕过正常的身份验证流程。

常见问题包括弱密码、默认密码、暴力破解防护不足、多因素认证缺失、会话标识管理不当以及密码重置流程不安全。

需要注意，认证和授权是两个不同概念。认证解决“你是谁”的问题，授权解决“你能访问什么”的问题。

2. 具体案例：短信验证码验证不完善

假设某网站通过手机短信验证码登录。

用户输入手机号后，服务器会生成六位数字验证码。但是系统既没有限制验证码的错误尝试次数，也没有进行合理的请求频率控制。

攻击者获得一个目标手机号后，可以向验证码验证接口反复提交不同的数字组合。

如果系统始终允许无限次尝试，攻击者就可能在验证码有效期内猜中正确验证码，最终获得相应账户的访问权限。

此外，如果验证码在验证成功后仍可重复使用，也可能造成重放攻击风险。

3. 安全危害

认证失效可能导致账户被盗、用户身份被冒用、个人信息泄露以及重要业务操作被非法执行。

4. 防护措施

系统应限制异常登录和验证码验证请求，合理设置验证码有效期，并在成功使用后立即将其作废。

对高风险账户和管理系统，应优先采用抗钓鱼能力更强的多因素认证方式。

会话管理方面，应在登录成功后重新生成会话标识，设置合理的失效机制，并在用户退出登录后使相关会话失效。

对于密码认证，还应检测常见弱密码和已泄露密码，避免单纯依靠复杂密码规则保障安全。

OWASP Top 10:2025

 

2.8 A08:2025 — 软件或数据完整性失效（Software or Data Integrity Failures）

1. 漏洞原理

完整性是信息安全的重要属性，主要指数据和软件在存储、传输及使用过程中，没有受到未经授权的修改。

软件或数据完整性失效是指系统没有充分验证软件代码、更新文件或者重要业务数据的真实性和完整性，导致被篡改的内容仍然被系统信任。

典型风险包括不安全反序列化、缺少数字签名的软件更新、直接信任客户端提交的关键业务数据，以及从不可信来源加载代码。

与 A03 软件供应链失效相比，A08 更强调具体软件或数据对象的信任边界和完整性校验。

2. 具体案例：客户端价格数据被篡改

假设某在线商城在用户提交订单时，由前端直接发送商品价格。

正常请求包含以下数据：

{
  "productId": 1001,
  "quantity": 1,
  "price": 999
}

但是，服务器没有重新计算商品的实际价格，而是直接相信客户端提交的 price 字段。

攻击者利用这一缺陷修改请求中的价格数据，将原本价值 999 元的商品以极低价格提交订单。

如果后端直接使用该金额创建支付订单，就可能造成经济损失。

这一案例体现了关键业务数据缺少完整性和可信性验证的问题，也涉及不安全设计中的信任边界缺陷。

3. 安全危害

完整性失效可能造成交易金额被篡改、身份数据伪造、系统配置遭到修改，严重情况下还可能导致恶意代码执行。

例如，如果自动更新程序没有验证更新包的签名和来源，攻击者一旦替换更新内容，就可能使用户安装恶意软件。

4. 防护措施

重要业务数据应由可信服务器重新计算或验证，不能仅依赖客户端提供的结果。

对于软件更新包、插件和其他可执行文件，应采用数字签名、可信证书和来源验证机制。

对不可信的序列化数据，应避免直接进行危险的反序列化操作，必要时采用安全的数据格式、严格的类型约束与完整性校验。

在 CI/CD 流程中，还应通过代码审查、制品签名以及发布权限管理，防止未经授权的程序或数据进入正式环境。

OWASP Top 10:2025

 

2.9 A09:2025 — 安全日志记录和告警失效（Security Logging & Alerting Failures）

1. 漏洞原理

安全日志是记录系统安全事件的重要机制，可以帮助管理员了解用户操作、识别异常行为，并在安全事件发生后开展追踪分析。

但仅仅记录日志并不意味着系统具备有效的安全监控能力。如果大量异常操作没有触发告警，或者管理员没有及时收到通知，攻击者就可能长期在系统中活动而不被发现。

因此，2025 年版本特别强调告警功能，使安全日志能够真正服务于事件检测和应急响应。

2. 具体案例：异常登录未触发告警

假设某企业内部管理平台记录了用户的所有登录行为，但没有配置异常登录检测规则。

某天，一名攻击者获得员工的账户密码，并从异常网络环境登录该账户。

随后，攻击者在短时间内下载大量内部文件，并多次尝试访问其他员工的业务数据。

虽然这些行为被写入日志，但系统没有对异常登录、大规模数据下载以及连续访问失败等行为进行关联分析，也没有向管理员发送告警。

直到企业发现重要信息泄露，安全人员才开始检查历史日志。由于事件发现时间较晚，攻击者可能已经获取大量资料。

3. 安全危害

日志和告警失效会降低企业发现攻击行为的能力，延长安全事件的持续时间，并增加后续调查、取证和恢复工作的难度。

如果日志还包含明文密码、访问令牌等敏感信息，日志系统本身也可能成为新的数据泄露来源。

4. 防护措施

企业应建立统一的安全日志体系，对登录失败、权限拒绝、重要数据修改、异常交易等事件进行记录。

日志应包含必要的时间、用户标识、请求标识和操作结果，并具备防篡改能力。

在监控方面，应针对暴力破解、异常登录、高频请求等行为配置告警规则，同时制定事件响应流程，明确告警出现后由谁负责确认和处置。

此外，还应定期测试告警机制是否有效，避免出现“日志正常记录，但安全人员始终没有发现问题”的情况。

OWASP Top 10:2025

 

2.10 A10:2025 — 异常条件处理不当（Mishandling of Exceptional Conditions）

1. 漏洞原理

异常条件处理不当是 2025 年新增的重要类别，主要指应用程序在遇到错误、超时、资源耗尽、网络故障或其他意外情况时，没有采取正确的安全处理方式。

正常情况下，系统能够按照预定业务流程运行。但是当外部服务突然中断、数据库查询失败或者程序出现未预期的状态时，系统可能进入一种不安全的运行状态。

其中一个重要概念是 Fail Securely，即安全失败原则。当系统无法确认某项操作是否安全时，应拒绝继续执行高风险操作，而不是默认允许。

2. 具体案例：支付异常导致重复扣款

假设某支付系统执行转账时，需要完成三个步骤：

第一步，从付款人的账户扣除金额；第二步，向收款人账户增加金额；第三步，记录交易结果。

正常情况下，这三个步骤应作为一个具有一致性保障的整体完成。

但是，开发人员没有正确设计异常回滚机制。

当系统执行完扣款操作后，网络突然中断，程序无法确认后续操作是否成功。如果用户重新发起转账请求，系统又缺乏幂等性控制，就可能重复执行扣款。

相反，如果某些步骤执行成功、某些步骤执行失败，也可能造成交易记录与实际账户余额不一致。

攻击者甚至可能通过重复触发异常状态，主动寻找这类业务逻辑缺陷。

3. 安全危害

异常条件处理不当可能导致服务崩溃、资源耗尽、交易错误、敏感信息泄露以及权限检查被绕过。

例如，服务器在数据库连接失败时向浏览器返回完整异常堆栈，可能暴露数据库类型、程序路径和内部组件信息。

4. 防护措施

关键业务流程应设计完整的错误处理机制，包括异常捕获、事务回滚、超时控制、重复请求保护和必要的资源释放。

对于支付、转账等重要操作，应采用数据库事务、幂等性标识以及可靠的状态恢复机制，防止异常情况下出现重复处理或数据不一致。

同时，应建立全局异常处理机制，对用户返回简洁、可理解的错误提示，而将详细技术信息保存在受到访问控制保护的内部日志中。

系统测试还应覆盖服务器中断、数据库不可用、网络延迟、资源不足等异常场景，而不能只验证正常业务流程。