A01:2025 - Broken Access Control

越权访问类：

成因：后端开发人员疏忽，未对用户的增删改查权限进行严格校验或根本没有校验
分类：可分为水平越权，垂直越权，无权限操作
- 水平越权类：服务器端在处理用户的增删改成时没有判断数据的所属人或所属主体导致的
- 垂直越权类：提权，低权限的发送高权限的请求，从而获得高权限的操作
- 做系统的时候考虑不到做权限控制或者做了权限控制但是做得漏洞百出
常见：

URL篡改：例如更改/user/1001为/user/1002

绕过客户端权限判断：前端按钮隐藏并不能限制后端访问

CORS配置不当导致恶意域名跨站读取数据

防御手段

所有权限校验必须在服务端完成

实施最小权限原则（PoLP）

使用访问控制模型（如RBAC、ABAC）

安全的对象引用映射（不直接暴露数据库ID）

对敏感操作添加二次验证或操作审计

jwt
：JWT 里已经包含了用户信息和过期时间等声明

无状态：服务器不保存 JWT 的签发记录，验证时只靠签名和过期时间判断它是否有效

如果是无状态 JWT，服务器没有存这个 JWT，所以即使你登出了，这个 JWT 在 11:00 之前仍然是有效的，任何人拿着它都能访问受保护的资源

解决方法：

1.缩短有效期

2.刷新令牌机制

3.引入黑名单，使其变为有状态；在登出或者检测到异常时，将该jwt的唯一标识加入黑名单中，验证时先查询黑名单

4.密钥轮换

jwt是一种标准协议，oauth是一个安全授权框架

A02:2025 - Security Misconfiguration

安全配置错误

1	使用了带有已知漏洞的库或框架，攻击者可能利用这些漏洞进行攻击

1 2	定期扫描和更新组件，确保不使用有已知漏洞的库。使用依赖项管理工具，避免版本冲突

A03:2025 - Software Supply Chain Failures

软件供应链故障

不会仔细跟踪所有组件的版本
该软件存在漏洞、未被支持或已过时
不会定期扫描漏洞，而是订阅与你所用组件相关的安全公告
没有加强供应链的每个环节，特别关注门禁和最低权限的应用
会以风险为基础、及时的方式修复或升级底层平台、框架和依赖。这种情况通常发生在修补是每月或季度一次、受变更控制的环境中，组织在修复漏洞之前可能面临数天甚至数月不必要的暴露风险
软件开发者不会测试更新、升级或补丁库的兼容性

集中生成和管理整个软件的软件物料清单
通过移除未使用的依赖、不必要的功能、组件、文件和文档，减少攻击面
持续盘点客户端和服务器端组件（如框架、库）及其依赖的版本，使用OWASP依赖追踪、OWASP依赖检查、retire.js等工具
持续监控常见漏洞与暴露（CVE）、国家漏洞数据库（NVD）和开源漏洞（OSV）等来源，以防你使用的组件存在漏洞。使用软件组成分析、软件供应链或以安全为核心的SBOM工具来自动化流程。订阅与您所使用组件相关的安全漏洞警报
只通过安全链路从官方（可信）来源获取组件
有意识地选择你使用的依赖版本，只有在需要时才升级

A04:2025 - Cryptographic Failures

加密错误

应该被加密的数据没有进行加密；
在代码中硬编码了密钥或密码；
使用了已经可以被破解或已经被证明有漏洞的加密算法；
使用了比较弱的密钥，可以很容易被猜到；
服务器配置不当或者应用程序 bug 导致的数据泄露

例如密码、银行卡号码、身份证号码和商业秘密等显而易见的敏感数据
各种数据保护法或隐私保护法规定的敏感数据，例如欧盟的通用数据保护条例(GDPR)，PCI数据安全标准(PCI DSS)等
需要从以下这些方面检查是否存在加密机制失效漏洞：

数据传输过程中是否是以明文的方式传输的？
程序中是否使用了已经被废弃的加密算法或者不安全的加密算法？是否使用了加密算法的不安全的模式？例如 ECB 模式。
秘钥强度是否足够？同一个秘钥是否用在了多处加密的地方？秘钥管理方法是否安全？ 秘钥是否很久没有更换过? 密钥是否硬编码到了代码中?
是否强制要求加密？例如有的接口通过一个参数来控制加不加密
是否验证了证书的合法性?
密码是否明文存储的？
是否使用了被弃用的哈希算法？例如 MD5 或 SHA1。是否是需要使用加密哈希算法时使用了非加密哈希算法?
是否使用了已弃用的加密填充方法？例如 PKCS1。
是否使用了已经被废弃的安全协议？例如web安全传输协议使用了 SSL。

对应用程序处理、存储或传输的数据进行分类和标记。根据隐私法律、监管要求或业务需求，识别哪些数据属于敏感。
将最敏感的密钥存储在硬件或云端的HSM中。
尽可能使用值得信赖的加密算法实现。
不要无谓地存储敏感数据。尽快丢弃它，或者使用符合PCI DSS的令牌化，甚至截断。未被保留的数据无法被盗取。
确保所有敏感数据在静止状态下加密。
确保有最新且强有力的标准算法、协议和密钥;使用正确的密钥管理。
使用仅限 >= TLS 1.2 协议加密所有传输中的数据，使用前向保密（FS）密码，取消对密码区块链（CBC）加密的支持，支持量子密钥更换算法。对于 HTTPS，强制加密，使用HTTP 严格传输安全（HSTS）。用工具检查所有东西。
对于包含敏感数据的响应，请禁用缓存。这包括你的CDN、网页服务器以及任何应用缓存（例如：Redis）。
根据数据分类应用必要的安全控制措施。
不要使用未加密的协议，如FTP和STARTTLS。避免使用SMTP传输机密数据。
使用强自适应和加盐哈希函数（带有工作因数（延迟因子）来存储密码，如 Argon2、yescrypt、scrypt 或 PBKDF2-HMAC-SHA-512。对于使用 bcrypt 的遗留系统，请访问 OWASP 速查表：密码存储
初始化向量必须根据作模式选择合适的方式。这可能意味着使用CSPRNG（加密安全伪随机数生成器）。对于需要nonce的模式，初始化向量（IV）不需要CSPRNG。在所有情况下，IV都不应对固定密钥重复使用。
一定要使用认证加密，而不是单纯的加密。
密钥应随机生成密码学，并以字节数组形式存储在内存中。如果使用密码，则必须通过适当的密码基密钥派生函数将其转换为密钥。
确保在适当情况下使用密码学随机性，且其种子不以可预测或低熵的方式进行。大多数现代API并不要求开发者为CSPRNG做种才能保证安全。
避免使用已废弃的密码函数、块构建方法和填充方案，如MD5、SHA1、密码块链模式（CBC）、PKCS 1 v1.5。
通过安全专家、为此目的设计的工具或两者兼有，确保设置和配置符合安全要求。

A05:2025 - Injection

用户提供的数据不会被应用程序验证、过滤或净化。
动态查询或无上下文转义的非参数化调用直接用于解释器中。
未净化数据用于对象关系映射（ORM）搜索参数中提取额外的敏感记录。
潜在的敌对数据被直接使用或串接。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。

1 2	使用参数化查询避免SQL注入。对输入进行严格的验证和清洗，防止不安全的代码执行

A06:2025 - Insecure Design

不安全设计

1	设计上没考虑安全问题

1	需求阶段加入"安全评审"，用"威胁建模"识别风险

A07:2025 - Authentication Failures

认证失败

允许自动化攻击，爆破，弱口令密码等等
允许用户创建已被泄露的已知凭证的新账户
使用纯文本、加密或弱哈希密码数据存储
它会在 URL 中暴露会话标识符、隐藏字段或其他客户端可访问的不安全位置

实施多因素认证（MFA）
会话ID在登录后重新生成，防止Session Fixation
Session应设置合理的过期时间
实施IP/设备绑定与异常行为监测
使用业界认证框架

A08:2025 - Software or Data Integrity Failures

完整性失效

1	软件和数据完整性失效涉及代码和基础设施，无法防止无效或不可信的代码或数据被当作可信且有效

使用数字签名或类似机制来验证软件或数据是否来自预期来源，且未被篡改。
确保库和依赖，如npm或Maven，只消耗可信仓库。如果你的风险等级较高，可以考虑托管一个经过审核的内部已知良好仓库。
确保代码和配置更改有审查流程，以最大限度减少恶意代码或配置被引入软件流水线的可能性。
确保您的CI/CD流水线有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性。
确保未签名或未加密的序列化数据不会来自不受信任的客户端，随后未经完整性检查或数字签名检测序列化数据的篡改或重放而被使用

A09:2025 - Security Logging and Alerting Failures

1	缺乏充分的日志记录和监控，使得攻击活动不易被察觉

1 2	开启详细的日志记录并定期审计。配置自动化监控工具，实时检测异常行为

A10:2025 - Mishandling of Exceptional Conditions

1 2	程序未能预防、检测和响应异常和不可预测的情况，导致崩溃、意外行为，有时甚至出现漏洞比如说条件竞争

1
2
3

捕捉并处理特殊情况确保我们的项目基础设施不会被遗弃应对不可预测的情况
添加速率限制、资源配额、限速及其他限制
包含严格的输入验证，以及集中式的错误处理、日志记录、监控和警报，以及全局异常处理程序