第一章 API安全概述与OWASP Top10介绍
先从一句大实话说起：为什么我们得关心API安全？
我个人习惯把API想象成数字世界的大门和窗口。你想想看，现在的应用哪个不是靠API活着的？前端调后端、微服务调微服务、第三方集成调第三方……说白了，API就是现代软件的骨架。骨架出问题，整个应用都得趴下。
但是，越是关键的东西，越容易成为攻击目标。我在项目中遇到过不止一次，业务方一脸天真地问我：“API不就传个数据嘛，有啥好防的？”我只好回一句：“你猜黑客最喜欢什么？就是你这种没设防的数据管道。”
嗯，开个玩笑。但现实是，OWASP（国际Web应用安全开源组织）从2019年就开始专门搞API安全榜单了。到2023年，OWASP API Top10早就成了安全圈的必读清单。你不看这个，就像你跑马拉松不看路标——大概率会掉坑里。
OWASP API Top10到底是个啥？
其实就是一份针对API安全风险的排行榜。OWASP每隔几年收集真实世界的攻击事件、渗透测试报告、漏洞披露，然后整理出最常见的10类安全风险。不是纸上谈兵，全是血淋淋的实战经验汇总。
我当年刚入门时还觉得，这不就跟Web安全差不多吗？直到我在一次红蓝对抗中被API的一个逻辑漏洞干翻——嗯，从那以后我再也不敢小看API安全了。
来，先看看2023年版本的榜单全貌：
| 排名 | API安全风险名称 | 核心风险描述 |
|---|---|---|
| API1 | 失效的对象级别授权 | 用户可以直接访问不应拥有的数据 |
| API2 | 失效的用户认证 | 认证机制存在缺陷，攻击者可以冒充他人 |
| API3 | 失效的对象属性级别授权 | 用户可以修改或读取不应暴露的字段 |
| API4 | 不受限制的资源消耗 | API容易被滥用导致资源耗尽 |
| API5 | 失效的功能级别授权 | 低权限用户可调用高权限接口 |
| API6 | 批量分配 | 客户端传入多余字段，服务端未做过滤 |
| API7 | 安全配置错误 | CORS、TLS、错误处理等配置不当 |
| API8 | 注入攻击 | SQL、NoSQL、命令注入等 |
| API9 | 不当的资产管理 | 废弃API、旧版本未下线、影子API |
| API10 | 日志与监控不足 | 攻击发生后无法追溯与响应 |
看到了吧？这10个类别，几乎覆盖了API从设计、开发、上线到运维的每一个环节。你问我这10个里面哪个最常见？我曾经跟一个甲方做渗透测试时发现，API1（失效对象级别授权）在现网中的出现率简直高得离谱。很多后端只是简单地拼了个ID就返回数据，根本不验证用户是否拥有访问权限。
传统Web安全 vs API安全：差异到底在哪？
很多同学会问：“这套东西跟OWASP Web Top10有什么不同？”其实我也被问过，问的人大概率没认真看过API的调用方式。传统Web安全关注的是页面、会话、HTML/JavaScript渲染。而API安全的核心是：端点、数据流、身份与权限的细粒度控制。
我习惯用一个表格来对比两者的关键差异：
| 维度 | 传统Web应用安全 | API安全 |
|---|---|---|
| 攻击面 | 页面、表单、Cookie | REST/GraphQL端点、JSON/XML参数 |
| 认证方式 | Session/Cookie为主 | JWT、OAuth2、为主 |
| 数据暴露 | 经过HTML模板渲染 | 直接返回原始JSON数据 |
| 权限粒度 | 页面级别的角色控制 | 对象+属性级别的字段控制 |
| 状态管理 | 有状态服务端会话 | 无状态（易出现伪造与窃取） |
| 扫描工具 | 传统DAST/SAST工具 | 需要专门理解API契约（如OpenAPI）的扫描器 |
你想想看，传统Web的攻击手法放到API上还能用吗？能用，但不够。比如SQL注入依然存在，但API返回的是JSON报文，攻击者可以直接读取结构化数据，比从HTML里解析方便得多。
一个真实案例：从“仅仅是ID遍历”到“全量用户数据泄露”
我记得2021年做某金融类App的渗透时，发现他们的用户资料接口是这样设计的：
GET /api/v1/user/profile?user_id=12345
Authorization: Bearer <>表面上看，认证到位了。但我仔细测试发现，后端只验证了是否有效，没有验证这个是否属于 user_id=12345。换句话说，我用自己的，把user_id改成其他人的ID，就能直接拉取别人的敏感信息——姓名、身份证号、银行卡后四位……
这就是典型的API1：失效的对象级别授权。如果当时业务没有做任何审计与监控，攻击者完全可以悄无声息地把全量用户数据扒下来。你问我怎么修复的？很简单，后端必须同时校验两样东西：的有效性和对应的主体与资源主体的归属关系。
核心框架图：API安全全景
我把这一章的知识点整合成一张全景图，方便你看清整个课程的结构逻辑。我们先从风险分类、攻防类型再到方法论，形成一个闭环：
API安全的三条铁律，我一直在用
讲完理论框架，我分享几条个人保持的安全原则。这些原则不是书上抄的，是我自己踩坑踩出来的：
- 永远不相信客户端传过来的任何标识符（比如userId、role、objectId），后端必须自己解析来获取真实身份。
- API的返回数据要“按需给”，不该暴露的字段一个都不要返回。我曾经见过一个接口把MySQL的连表查询错误信息直接抛给前端……黑客连SQL注入都不需要了。
- 日志和监控不是锦上添花，是最后一道防线。你想想看，如果没有日志，你连攻击者来过都不知道，怎么修复？怎么溯源？我曾经在某次应急响应时，发现攻击流量已经跑了三个月，而对方系统竟然没有一条审计日志——说实话，我当时整个人都麻了。
好，第一章的内容就到这里。先把这些概念吃透，后面的章节我会带你逐条分析OWASP Top10的每一个风险，并配上真实的测试方法和代码案例。准备好了就继续往下翻。