API 认证检查查什么
接口的认证问题往往不是「完全没有认证」，而是覆盖面不全：新版本接口做了校验、老版本没有；读接口受控、写接口漏了；主网关校验了、内部直连端口没有。检查因此用端点矩阵的方式推进：按接口清单分别用无凭据和失效凭据访问，逐条记录返回，再区分「业务上本就公开」的接口。令牌的生命周期同样要查——注销后的旧令牌还能不能读数据，是很多系统的通病。
基本信息
| 核查项 | 认证覆盖率、令牌生命周期、失败处理一致性 |
|---|---|
| 测试矩阵 | 无凭据 × 失效凭据 × 读接口 × 写接口 |
| 凭据来源 | 自有测试账号；注销后保留旧令牌用于重放 |
| 判定口径 | 所有需认证的端点必须统一拒绝，公开接口需有业务说明 |
| 修复方向 | 网关统一认证，例外接口清单化审批 |
典型使用场景
- 新系统接口安全评审的基础项
- 评估多版本并存的接口：v1 与 v2 的认证是否一致
- 核查移动端与旧版客户端的接口，这类入口常因兼容性被放宽
- 验证令牌注销机制：改密、注销、降权后旧令牌是否立即失效
- 为越权类问题提供前置结论：认证缺失会放大授权缺陷
验证步骤
验证步骤
# 1. 无凭据访问读接口与写接口，分别记录返回
curl -s -o /dev/null -w 'no-auth read %{http_code}\n' https://api.example.com/v1/users/me
curl -s -o /dev/null -w 'no-auth write %{http_code}\n' -X POST https://api.example.com/v1/orders -d '{}'
# 2. 用注销后的旧令牌重放只读请求
curl -s -H 'Authorization: Bearer <已注销令牌>' https://api.example.com/v1/users/me | head -5
# 3. 核对内部与管理接口是否有独立认证，不依赖前端网关
# 4. 区分业务公开接口（健康检查、静态资源）并单独标注响应与判断
| 响应 | 含义 | 处置 |
|---|---|---|
| 401 或 403 | 认证与鉴权正常拒绝 | 记录为已核查 |
| 200 且返回业务数据 | 认证缺失 | 列缺陷，评估数据敏感度后定级 |
| 200 但返回空结果 | 可能仅过滤数据未校验身份 | 进一步确认是否可跨账号读取 |
| 注销后仍返回数据 | 令牌未失效 | 单独列为会话失效不彻底问题 |
公开接口（健康检查、静态资源、开放数据）应列入白名单并在报告中说明，避免把所有匿名可访问端点都判为缺陷。
接口版本差异是常见漏点：老版本常为了兼容遗留客户端而放宽校验，检查时要把全部版本路径都纳入矩阵。