当业务从网页转向多端（App、小程序、开放平台、第三方集成），API 就从“内部接口”变成了真正的对外边界。问题也随之变化：以前只要守住登录，现在每一个接口都是入口，而大量接口的鉴权是“当时能用就行”。
一、认证：先分清三种凭证的适用场景
| 方式 | 适用场景 | 主要风险 |
|---|---|---|
| JWT / Access Token | 终端用户访问自有服务 | 无法即时撤回，需控制有效期与刷新机制 |
| API Key | 服务商对服务商调用 | 易泄露，必须绑定调用方与频率限制 |
| 双向 TLS / 签名 | 高价值接口、金融类场景 | 实现复杂，密钥管理成本高 |
实务中最常见的三个问题：一是把 JWT 有效期设得过长（几天甚至几个月），导致无法回收；二是把 API Key 硬编码进客户端，逆向即可得到；三是在网关做了认证，但下游服务默认信任任何已到达的请求，绕过网关的路径就此产生。
二、授权：最容易被忽略的一层
认证通过不等于有权限。典型的越权分两类：
- 水平越权：普通用户能读取他人数据。根因是接口从请求里取资源 ID，却没有校验该资源是否属于当前用户。
- 垂直越权：普通用户能调用管理员接口。根因是权限校验只在前端菜单层面做了，后端接口本身没有校验。
防御上建议统一在一个中间层完成，而不是在控制层里逐个手写：对需要对象级权限的接口，强制从会话取用户身份并与资源归属比对；对管理员接口，用路由前缀或旁路注解绑定角色要求。审核时应把“每个接口的权限声明是否存在”当作扫描项，未声明的接口默认拒绝。
三、网关层值得做的六件事
把安全能力前置到网关，能避免在每个服务里重复实现：
- 限流与配额：按调用方与接口维度限制，而不仅是全局总量。
- 请求体积与字段校验：限制请求体大小，拒绝未知字段，防止参数注入与滥用。
- 敏感数据脱敏：响应中的手机号、证件号统一在出口层处理。
- 重放防护：对重要接口要求时间戳 + nonce，并限制时间窗口。
- 越权检测告警：当同一调用方短时间内大量返回 403 时告警，往往是扫描行为。
- 日志留全：记录调用方、接口、参数摘要、响应码与耗时，排障与取证都依赖它。
四、上线前的检查与上线后的监测
上线前最有效的手段是接口清单核对：拉出实际暴露的路由列表，逐个确认是否有鉴权、是否有权限声明、是否曾在文档中公开。大量事故源于一个已经被遗忘的测试接口或旧版本接口。
上线后建议重点监测：单调用方的异常请求量、鉴权失败率与 403 分布、接口的 4xx/5xx 趋势、以及新增的未在清单中的接口。最后一项需要接口清单与网关流量做定期比对，这比单看流量异常更有价值。
五、两个观念性的提醒
一是不要依靠“隐藏接口”来防护。不公开文档、不写在前端代码里，都无法抵抗知道接口结构的攻击者。安全必须依靠鉴权与权限体系。
二是把 API 安全纳入发布流程。新接口上线前必须回答“谁能调、能调什么、有频率限制吗”三个问题。把这三个问题变成发布清单的必填项，比事后扫描更能解决问题。
