5.2 API安全
5.2 API 安全
本节摘要：API 是云时代系统的承重墙——所有功能经由它暴露，所有攻击也经由它进入。本节按攻击类别逐类拆解 API 的防线：认证与令牌、授权（尤其是最常失守的对象级授权）、输入校验、限流与配额、版本与下线治理，最后给一张 API 防线自查清单。
API 是云时代的承重墙
云原生架构的一个事实是：系统的每一个能力都以 API 形式存在——前端调用后端走 API，服务之间调用走 API，连基础设施的操作也走 API。这个架构选择把"攻击面"三个字变得无比具体：API 清单几乎就是攻击面清单。第二章说攻击面要持续管理，在应用层，管理的对象就是每一个端点。
API 风险的特殊性在于它的"合法外观"：攻击者不需要砸门，用正常协议、合法格式发请求即可，很多攻击与正常业务流量的区别只在参数与频率。这决定了 API 防线的设计哲学——不能靠"认出坏人"，要靠"严格判定每个请求的资格"。资格判定分三层：你是谁（认证）、你能对这件事做什么（授权）、这件事做得合不合规矩（校验与限流）。
逐类拆解攻击与控制
认证层：API 凭据是数字世界的钥匙，管理原则全部继承第四章——短时效令牌优于长期密钥、凭据不入代码仓库、签名算法与密钥轮换有治理。移动端与前端应用的 API 凭据要假定公开（反编译即可提取），因此它们的认证设计必须不依赖"密钥保密"而是依赖短时效与风控。
授权层：认证回答"你是谁"，授权回答"你能不能动这条数据"。API 最常见的失守是对象级授权缺失：接口校验了登录态，却不校验"这条记录是不是你的"——把请求里的单号递增一位，就能看到别人的订单。这类缺陷在行业漏洞统计里常年位居 API 类榜首，防御写法朴素而严格：每个涉及具体对象的请求，服务端都要核对"当前身份对该对象的归属或授权"，不能信任客户端传来的任何"我有权"的声明。
输入校验层：按接口契约严格校验参数类型、范围与格式，拒绝一切契约之外的内容。注入类攻击（命令注入、注入式查询）的根源都是"数据被当成了指令"，严格校验与参数化处理是正解。文件上传是重灾区：类型、大小、内容魔数、存储位置与访问方式四项逐一校验，上传内容按 5.1 威胁建模的结论当不可信数据处理。
限流与配额层：认证与授权管资格，限流管节奏。没有限流的 API 等于邀请暴力枚举与资源滥用——撞库攻击的本质就是无限流下的密码枚举。限流按身份与来源双向设阈，敏感操作（登录、找回密码、支付确认）叠加更严格的节奏与二次验证。
图 5-2：一次对象级授权攻击被拦下的全过程
时序推演：一轮撞库攻击撞上层层防线
把限流与风控的配合演成一条时序。攻击者拿泄露的账号密码库对登录接口做批量尝试，防线的意义在于让每一轮尝试的成本递增、且行为全程留痕：
三个设计要点藏在时序里。其一，失败提示保持通用——"账号或密码错误"不给枚举者任何确认信号。其二，处置是递进的：限流抬成本、二次验证抬门槛、观察名单做长期画像，单层控制都不足以了事。其三，审计日志反哺风控基线，防线随攻击演化——这正是第六章"监控与响应闭环"在应用层的预演。
版本治理与下线纪律
API 治理里有一件常有的事故源：老版本无人管。接口下线不是删除代码，是一套带缓冲的流程——新版发布时旧版声明废弃期限、期限内双版本并行、到期前对仍在调用旧版的身份逐一通知、到期硬切并观察。安全视角的理由很硬：旧版本缺少新加的控制（加密要求、限流策略、字段脱敏），攻击者专挑旧版打。行业里多次出现"新接口安全了，攻击者绕到没人管的旧接口"的案例，下线纪律松散的团队等于给自己留了后门。
配套的还有 API 清单管理：任何对外暴露的端点都应登记在册（含临时调试接口的登记与到期自动回收）。影子 API——没进清单却真实暴露的端点——是渗透测试最常见的战果之一，清单与网关路由的定期比对可以自动发现它们。
API 防线自查清单
收尾给一张可执行清单，按序自查：全部端点是否都有登记与负责人；认证是否全部短时效令牌；对象级授权是否有统一写法（建议框架层强制而非每接口手写）；输入校验是否按契约严格模式；敏感接口是否叠加限流与二次验证；错误信息是否不泄漏内部细节（报错里带堆栈与 SQL 片段是老朋友了）；废弃版本是否有到期硬切；网关日志是否全量留存并接第六章的监控。八问全部能答"是"，API 这面承重墙才算砌严实。
一个完整案例：弹屏接口的越权修复全程
把对象级授权的修复走一遍真实节奏。背景：客服系统的来电弹屏接口按手机号返回用户资料，鉴权只校验了客服登录态。渗透测试报告：任何登录客服遍历手机号可拉取全量用户资料。
修复分四步。第一步紧急止血：接口临时下线，客服改走后台查询流程。第二步根因修复：接口增加归属与授权校验——客服只能查询其服务工单关联的用户；跨工单查询走审批接口并留痕。第三步同类排查：全系统按"接口参数里带对象标识"的条件扫描，又发现两个同型缺陷（物流详情接口、发票下载接口），一并修复——对象级授权缺失从来不是单点问题，是一个编码习惯问题。第四步防复发：把对象级校验做成框架层统一拦截器，新接口默认生效，绕行需评审。
这个案例的推广价值在第三步与第四步：单点修复是补丁，习惯修复才是治理。考试场景题里对应的判断是——发现一处对象级授权缺失后，正确选项是"排查同类接口并统一修法"，而不是只修报告点。
API 清单的盘点实操
影子 API 的治理从盘点开始，给一条实操动线。第一层，查声明面：接口文档、网关路由表、代码里的路由注册——这是"应该存在的 API"。第二层，查实际面：网关访问日志里出现过的全部路径与外部探测数据——这是"真实存在的 API"。两个面做差集：实际有、声明没有的就是影子 API，逐个决断——纳入管理或下线回收。第三层，查遗忘面：历史版本接口（7.2 讲过的下线纪律）与测试专用接口，是最容易"声明过但忘了关"的存量。
盘点的频率季度起步，有条件的话接自动化：网关日志与注册清单的比对脚本周跑一次，新出现的未注册路径直接开单。影子 API 的生命周期管理，与配置漂移（6.3）是同一个治理范式——真实状态与声明状态的持续对账。
本节要点回顾
- API 清单几乎就是攻击面清单：端点登记、影子 API 对账、版本下线纪律，是清单层面的三件套。
- 资格判定分三层：认证管你是谁、授权管你能不能动这条数据、校验与限流管做得合不合规矩，缺一层漏一类攻击。
- 对象级授权是最常失守的一层：修法是框架层统一拦截而非每接口手写，发现一处要排查同类。
- 限流是安全工具不是性能工具：把枚举类攻击的成本抬到不可行，处置按限流、二次验证、观察名单递进。
- 旧版本是被遗忘的后门：废弃接口缺少新控制，下线要有缓冲期更要有硬切日。
接口防线立住之后，下一节看架构变化带来的新边界：当一台服务器被拆成一百个函数与微服务，信任关系怎么重画。