风险识别框架：OWASP API Top 10 风险解读、风险分类模型、风险等级评估标准
做 API 安全审计，第一步不是拿工具扫漏洞，而是先搞清楚——我们到底在防什么。
我见过太多团队，上来就部署 WAF、上网关、配认证，结果被一个「未授权访问」打穿。为什么？因为连风险清单都没对齐。
这一章，我们就来搭风险识别框架。说白了，就是三件事：知道有哪些坑（Top 10）、学会怎么归类（分类模型）、能判断坑有多深（等级评估）。
2.1 OWASP API Top 10：最该先看的风险清单
OWASP 每隔几年会发布一份 API 安全风险排名。目前最新是 2023 版。我个人习惯，每次接手新项目，第一件事就是拿这份清单去对接口文档。
| 排名 | 风险名称 | 一句话解释 |
|---|---|---|
| API1:2023 | 对象级授权失效 | 用户 A 能访问用户 B 的数据（比如改 URL 里的 ID） |
| API2:2023 | 认证失效 | 弱密码、 泄露、Session 固定 |
| API3:2023 | 对象属性级授权失效 | 能修改不该改的字段（比如把 isAdmin 改成 true） |
| API4:2023 | 资源消耗无限制 | 没有限流、没有分页，一个请求打崩后端 |
| API5:2023 | 功能级授权失效 | 普通用户能调用管理员接口 |
| API6:2023 | 服务端请求伪造（SSRF） | API 帮你访问内网资源 |
| API7:2023 | 安全配置错误 | CORS 乱配、Debug 接口没关、默认密码没改 |
| API8:2023 | 注入攻击 | SQL、NoSQL、命令注入 |
| API9:2023 | 资产管理不当 | 老版本接口没下线、文档暴露在公网 |
| API10:2023 | 日志与监控不足 | 被攻击了都不知道，审计日志是空的 |
我的经验：Top 10 里，API1 和 API3 占了实际漏洞的 60% 以上。很多公司花大价钱买 WAF，结果被一个「遍历用户 ID」的接口打穿。审计时，优先查授权。
2.2 风险分类模型：把问题装进正确的抽屉
光有清单还不够。你想想看，一个「认证失效」和一个「配置错误」，修复方式完全不同。所以我们需要一个分类模型，把风险分门别类。
我常用的分类模型分三层：
- 第一层：攻击面——风险出现在哪个环节？（认证层、授权层、数据层、传输层、配置层）
- 第二层：攻击手法——攻击者怎么利用的？（暴力破解、参数篡改、注入、重放）
- 第三层：影响范围——打穿之后能造成什么后果？（数据泄露、服务中断、权限提升）
举个例子：一个「未授权访问管理员接口」的风险，分类就是：授权层 → 参数篡改 → 权限提升。这样分类，后续修复和审计都能精准定位。
小技巧：我建议每个 API 接口在文档里就标注好「风险分类标签」。比如 GET /api/users/{id} 的标签是 [授权层][对象级][数据泄露]。审计时一目了然。
2.3 风险等级评估标准：给风险打分
分类完了，接下来要排优先级。不可能所有风险都立刻修，资源有限，得先修最要命的。
我一般用 CVSS 3.1 的简化版，只取三个维度：
- 利用难度（低/中/高）——攻击者需要什么条件？有工具就能扫？还是需要内网权限？
- 影响程度（低/中/高）——数据泄露？服务不可用？还是只是信息泄露？
- 暴露面（公网/内网/管理网）——这个接口谁都能访问？还是只有内部能用？
然后按下面的矩阵打分：
| 利用难度 | 影响程度 | 暴露面 | 最终等级 |
|---|---|---|---|
| 低 | 高 | 公网 | 严重 |
| 低 | 中 | 公网 | 高危 |
| 中 | 高 | 内网 | 高危 |
| 高 | 高 | 公网 | 中危 |
| 低 | 低 | 内网 | 低危 |
| 高 | 低 | 管理网 | 信息 |
注意：我曾经遇到一个团队，把所有「内网接口」的风险都标成低危。结果攻击者通过 SSRF 打穿内网，直接拿到数据库。暴露面不能只看网络位置，还要看接口的敏感程度。
2.4 实战：给一个真实风险做完整评估
我们拿一个真实场景来走一遍流程。假设审计发现：
GET /api/orders?userId=123 这个接口，没有校验当前登录用户是不是 userId=123 本人。攻击者把 userId 改成 456，就能看到别人的订单。
按我们的框架：
- OWASP 分类：API1:2023 对象级授权失效
- 分类模型：授权层 → 参数篡改 → 数据泄露
- 等级评估：
- 利用难度：低（改个参数就行）
- 影响程度：高（订单数据含姓名、地址、手机号）
- 暴露面：公网（这个接口对前端 App 开放）
- 最终等级：严重
我的建议：每个风险都要走完这三步。别跳步。我见过有人直接给「严重」等级，但说不出为什么严重。审计报告要有理有据，不然开发不认账。
嗯，到这里，风险识别框架就搭好了。你有了清单（Top 10）、有了抽屉（分类模型）、有了尺子（等级评估）。下一件事，就是拿着这个框架，去审计真实的 API 接口了。