OWASP Top 10 是面向开发者和应用安全人员的 Web 安全风险清单。它不是漏洞字典，也不是一套拿来打勾的合规表，而是帮助团队优先处理最常见、影响最大的应用安全问题。

当前正式版本是 OWASP Top 10:2025。与专门关注接口的 API Security Top 10 不同，它覆盖整个 Web 应用，包括身份认证、权限控制、业务设计、代码、依赖、配置、数据保护和安全运营。

Web 应用攻击面
图 1：Web 应用的攻击面不只在页面和接口，还包括依赖、CI/CD、云配置与第三方服务。

2025 版有哪些变化

2025 版继续把访问控制失效列为第一风险，同时做了三项明显调整：

  • 将“存在已知漏洞和过时组件”扩大为覆盖依赖、构建、制品和发布链路的软件供应链失效；

  • 新增异常情况处理不当，关注失败开放、错误状态和边界条件；

  • 将 SSRF 等问题合并到更大的访问控制类别中。

这些变化说明，现代 Web 安全已经不只是防 SQL 注入，还要管权限、依赖、流水线、配置和系统异常状态。

OWASP Web Application Top 10

OWASP Web Application Top 10 总览

图 2：十类风险可以归纳为身份与设计、代码与数据、平台供应链、发现与响应四组。

编号

风险

常见表现

核心防护

A01

访问控制失效

修改 URL 或对象 ID 后访问他人数据；普通用户调用管理功能

默认拒绝、服务端统一鉴权、校验资源归属

A02

安全配置错误

调试模式未关闭、默认账号、CORS 过宽、错误栈泄露

配置基线、自动化检查、最小化安装

A03

软件供应链失效

使用过期依赖、恶意包、被篡改的构建工具或制品

SBOM、依赖扫描、锁定版本、保护 CI/CD

A04

加密机制失效

明文传输、弱算法、密钥硬编码、密码存储不当

TLS、成熟算法、密钥管理、密码专用哈希

A05

注入

SQL、命令、模板、LDAP 或脚本注入

参数化查询、上下文编码、输入白名单

A06

不安全设计

找回密码可绕过、转账缺少限额、敏感操作无二次确认

威胁建模、滥用案例、业务安全约束

A07

身份认证失效

弱密码、会话固定、Token 长期有效、验证码可绕过

成熟认证框架、MFA、会话失效与风控

A08

软件或数据完整性失效

更新包、反序列化数据或流水线产物未校验

签名校验、可信来源、完整性验证

A09

安全日志与告警失效

攻击行为未记录；记录了却没人收到告警

统一审计日志、实时告警、关联分析

A10

异常情况处理不当

服务异常时绕过校验、失败开放、资源未释放

失败关闭、统一异常处理、超时与资源上限

A01：访问控制失效

访问控制回答的是：当前用户能不能执行这个操作，能不能访问这条数据。

前端隐藏按钮不等于权限控制。攻击者可以直接构造 HTTP 请求，因此权限判断必须放在服务端，并且覆盖读取、创建、修改、删除和导出等所有操作。

常见错误包括：

  • 只判断是否登录，不判断角色和资源归属；

  • 直接使用客户端传入的 userId、tenantId 作为授权依据；

  • 管理接口与普通接口共用控制器，却遗漏方法级权限；

  • 文件下载只校验路径存在，没有校验文件属于谁。

最稳妥的做法是默认拒绝，把用户、租户和数据范围直接写入查询条件，而不是查出数据后再补一次判断。

A02：安全配置错误

很多漏洞并不来自业务代码，而是来自“能运行但不安全”的配置，例如：

  • 生产环境开启调试模式；

  • 服务器保留示例应用、默认账号和无用端口；

  • 云存储桶或数据库暴露到公网；

  • Cookie 缺少 Secure、HttpOnly 或合理的 SameSite；

  • 异常响应返回完整堆栈、SQL 和服务器版本。

安全配置应当像代码一样进入版本管理，通过模板、IaC 和自动化检查保持开发、测试与生产环境的一致性。

A03：软件供应链失效

现代项目通常依赖大量开源库、包管理器、容器镜像、构建插件和 CI/CD 工具。攻击者不一定攻击你的代码，也可能攻击你信任的工具链。

防护重点包括：

  • 生成并维护 SBOM，掌握直接依赖和传递依赖；

  • 使用锁文件和可信仓库，避免随意拉取未知包；

  • 持续扫描 CVE，并制定高风险漏洞修复时限；

  • 对构建制品签名并校验来源；

  • 限制代码仓库、制品库和流水线的写权限。

依赖扫描只解决“已知漏洞”，无法单独解决恶意包、账号被盗和流水线篡改，因此供应链还需要权限、审计与制品完整性控制。

A04：加密机制失效

加密失败通常不是“完全没加密”，而是算法、密钥或使用方式不正确。

例如：

  • 使用 MD5、SHA-1 直接存密码；

  • 在源码或配置文件里写死密钥；

  • 使用固定 IV 或重复 nonce；

  • 只加密数据库，却在日志、备份和消息队列中泄露明文；

  • HTTPS 配置不完整，内部服务仍然明文传输敏感数据。

密码应使用 Argon2id、scrypt 或 bcrypt 等专用密码哈希算法；业务数据加密则要使用成熟的加密模式和独立密钥管理系统。

A05：注入

当不可信输入被拼接到 SQL、系统命令、模板或脚本中，解释器可能把数据当成指令执行。

防注入的核心不是“过滤几个特殊字符”，而是让代码和数据彻底分离：

  • SQL 使用参数化查询；

  • 命令执行尽量调用固定参数的系统 API；

  • HTML 输出做上下文编码；

  • 动态查询只允许白名单字段和排序规则；

  • 禁止把用户输入直接交给模板、表达式或反序列化引擎。

典型攻击链与防线

图 3：安全控制应在输入、权限、执行环境和监控四个位置同时建立防线。

A06：不安全设计

不安全设计是架构或业务规则本身存在缺陷，后期加 WAF 或补输入校验也无法真正解决。

例如：

  • 找回密码只验证一个容易获取的信息；

  • 优惠券可以无限尝试和重复领取；

  • 转账没有单笔限额、日限额和异常行为验证；

  • 高权限操作没有审批、二次确认或操作留痕。

设计阶段应进行威胁建模，并同时编写正常用例和滥用用例。安全规则要成为领域模型的一部分，而不是上线前临时加几个拦截器。

A07：身份认证失效

身份认证确认“你是谁”，访问控制决定“你能做什么”。两者经常被混为一谈。

常见问题包括弱密码、撞库保护不足、会话固定、登录后不更新 Session ID、退出后 Token 仍然有效，以及密码重置流程比正常登录更弱。

实际项目应优先使用成熟认证框架，并落实：

  • MFA 或高风险操作的二次认证；

  • 登录限速、设备识别和异常行为检测；

  • 短生命周期 Access Token 与可撤销的 Refresh Token；

  • 修改密码、退出登录和账号冻结后的会话失效；

  • Cookie 的安全属性和 CSRF 防护。

A08：软件或数据完整性失效

完整性控制要确认软件、配置和数据“没有被替换或篡改”。

典型风险包括：

  • 客户端自动更新但不校验签名；

  • CI/CD 直接执行来自不可信分支的脚本；

  • 从第三方地址下载文件后立即运行；

  • 对不可信数据进行危险反序列化；

  • Webhook 只接收数据，不校验签名和时间戳。

解决思路是建立可信来源、签名验证、哈希校验和最小权限，避免把“能下载到”误认为“可以信任”。

A09：安全日志与告警失效

没有日志，攻击发生后无法还原；只有日志没有告警，攻击发生时仍然没人知道。

至少应记录：

  • 登录失败、密码重置、MFA 变更；

  • 权限拒绝、管理操作和敏感数据导出；

  • 频繁异常请求、限流触发和输入校验失败；

  • 账号、角色、密钥和安全配置的变化。

日志中不能写入明文密码、完整 Token、银行卡号等敏感信息。真正有效的安全运营还需要告警规则、负责人和响应流程。

A10：异常情况处理不当

系统在正常路径上可能很安全，但在超时、依赖故障、资源不足或数据异常时进入不安全状态。

例如：

  • 权限服务超时后默认放行；

  • 签名校验异常时继续处理请求；

  • 库存锁失败后仍然创建订单；

  • 上传解析失败却没有清理临时文件；

  • 重试没有上限，最终拖垮线程和下游服务。

安全系统应当失败关闭：无法确认安全条件时拒绝操作。同时设置超时、并发上限、资源配额、幂等性和统一异常响应，避免内部错误信息直接暴露给用户。

如何在项目中落地

OWASP Top 10 的价值不在于背诵十个名词，而在于把它转成开发流程中的控制项。

安全开发生命周期

图 4：安全应贯穿需求、设计、编码、测试、发布和运行，而不是上线前临时扫描一次。

设计阶段

明确数据分级、角色权限、租户边界和敏感业务限制；对登录、支付、文件上传、密码重置等高风险流程进行威胁建模。

编码阶段

使用统一鉴权组件、参数化查询、安全加密库和最小化 DTO；禁止硬编码密钥，依赖版本进入统一管理。

测试阶段

除常规 SAST、DAST 和依赖扫描外，还要做越权测试、业务滥用测试、异常路径测试和配置检查。很多访问控制与业务逻辑问题无法依靠扫描器自动发现。

发布与运行阶段

检查生产配置、镜像和制品来源；建立日志告警、漏洞响应、密钥轮换和依赖升级机制。发现风险后要能定位负责人并快速回滚或修复。

两个常见误区

误区一：接入 WAF 就覆盖 OWASP Top 10。

WAF 能拦截部分注入和恶意流量，但无法理解订单归属、转账限额和角色权限。业务安全仍然必须由应用自身实现。

误区二：通过一次漏洞扫描就算完成安全建设。

扫描器擅长识别已知模式，却很难发现不安全设计、业务滥用、复杂越权和异常路径。OWASP Top 10 应作为安全开发基线，而不是一次性检查报告。

总结

OWASP Web Application Top 10 覆盖的是整个应用体系：

  • 身份是否可信；

  • 权限是否在服务端严格执行；

  • 业务流程是否考虑滥用；

  • 输入、数据和密钥是否安全处理；

  • 依赖、构建与配置是否可信；

  • 异常发生时系统是否安全失败；

  • 攻击出现后能否及时发现和响应。

真正有效的做法，是把这些要求落实到统一鉴权、安全设计、自动化测试、供应链治理和持续监控中。

参考资料

  1. OWASP Top 10:2025 主页
    https://owasp.org/Top10/2025/

  2. OWASP Top Ten Web Application Security Risks
    https://owasp.org/www-project-top-ten/

  3. OWASP Top 10:2025 Introduction
    https://owasp.org/Top10/2025/0x00_2025-Introduction/

  4. OWASP Developer Guide：OWASP Top 10
    https://devguide.owasp.org/en/07-training-education/05-top-ten/

  5. OWASP Application Security Verification Standard
    https://owasp.org/www-project-application-security-verification-standard/

  6. OWASP Cheat Sheet Series
    https://cheatsheetseries.owasp.org/