REST API 安全清单

安全不是一蹴而就的,而是在设计、开发、部署、运维的每个环节中持续关注的结果。一份详尽的安全清单,可以帮助团队在每个阶段发现潜在的安全问题,避免在生产环境中暴露漏洞。

本文档整理了 REST API 安全的完整检查清单,分为十个类别,每个检查项都给出了具体的检查标准和验证方法。

认证与授权清单

认证机制

检查项检查标准验证方法
□ 认证凭证安全传输所有认证请求必须通过 HTTPS检查请求是否重定向 HTTP 到 HTTPS
□ 认证凭证强度密码复杂度满足要求(8+字符,大小写混合,特殊字符)代码审查 + 暴力破解测试
□ 账户锁定策略连续失败登录后锁定账户(如 5 次失败锁定 30 分钟)暴力破解测试
□ 会话超时空闲会话在合理时间内过期(如 30 分钟无活动)功能测试
□ 多因素认证高敏感 API 支持 MFA配置审查
□ 密码存储使用 bcrypt/Argon2 等强哈希算法,不使用 MD5/SHA1代码审查

API Key 管理

检查项检查标准验证方法
□ Key 生成使用加密安全的随机数生成器,长度 >= 32 字符代码审查
□ Key 传输通过 Header 传递,不使用 URL 参数代码审查
□ Key 存储服务端只存储 Key 的哈希值,不存储明文数据库审查
□ Key 轮转支持 Key 轮转,旧 Key 有宽限期功能测试
□ Key 撤销支持立即撤销泄露的 Key功能测试
□ Key 作用域支持细粒度 Scope 限制配置审查

JWT Token

检查项检查标准验证方法
□ 签名算法使用 RS256/ES256,不使用 HS256 在多客户端场景代码审查
□ Token 有效期Access Token 有效期 <= 1 小时代码审查
□ Token 刷新支持 Refresh Token 续期功能测试
□ Token 撤销支持 Token 黑名单或短有效期功能测试
□ 敏感信息Payload 不包含密码、信用卡等敏感信息代码审查
□ 算法白名单服务端硬编码期望的算法代码审查

授权控制

检查项检查标准验证方法
□ 最小权限每个 API/服务只授予必要的权限权限审计
□ 所有权检查API 校验用户与资源的所有权关系渗透测试
□ 垂直越权低权限用户无法访问高权限 API渗透测试
□ 水平越权用户无法访问其他用户的数据渗透测试
□ 授权决策日志记录所有授权失败事件日志审查

输入验证清单

参数校验

检查项检查标准验证方法
□ 类型校验所有参数都有正确的类型定义代码审查
□ 长度校验字符串参数有最大长度限制功能测试
□ 格式校验使用正则表达式验证格式(邮箱、日期、URL 等)模糊测试
□ 范围校验数值参数有合理范围功能测试
□ 枚举校验使用枚举限制可选值,不使用字符串拼接代码审查
□ 必填校验必填参数有明确声明代码审查

SQL 注入防护

检查项检查标准验证方法
□ 参数化查询所有数据库查询使用参数化或 ORM代码审查
□ 禁止字符串拼接代码中不存在 SQL 字符串拼接代码扫描
□ 白名单表名动态表名/列名使用白名单代码审查
□ 最小权限账号数据库账号只有必要的表权限配置审查

NoSQL 注入防护

检查项检查标准验证方法
□ 类型校验查询条件与字段类型匹配代码审查
□ 操作符限制不允许 $where、$eval 等危险操作符代码审查
□ 输入清理用户输入经过适当清理代码审查

命令注入防护

检查项检查标准验证方法
□ 避免系统调用不使用 Runtime.exec() 执行用户输入代码审查
□ 参数数组如必须执行命令,使用参数数组而非字符串拼接代码审查
□ 白名单命令只允许执行预定义的命令代码审查

输出编码清单

响应格式

检查项检查标准验证方法
□ 内容类型正确设置 Content-Type,不使用 text/html响应头审查
□ 字符编码统一使用 UTF-8代码审查
□ JSON 安全转义特殊字符,防止 XSS代码审查

敏感数据处理

检查项检查标准验证方法
□ 字段过滤API 响应不包含内部字段(_id、__v 等)功能测试
□ 密码屏蔽用户密码、永不过期响应中代码审查
□ 信用卡掩码完整信用卡号只返回后 4 位代码审查
□ 日志脱敏日志不记录敏感信息(密码、Token、身份证号)日志审查

加密清单

传输加密

检查项检查标准验证方法
□ HTTPS 强制HTTP 请求重定向到 HTTPS功能测试
□ TLS 版本只允许 TLS 1.2+配置审查
□ 证书有效服务器证书有效且未过期SSL 扫描
□ HSTS配置 Strict-Transport-Security 头响应头审查
□ 安全 CookieCookie 设置 Secure 和 HttpOnly 标志响应头审查

存储加密

检查项检查标准验证方法
□ 敏感数据加密数据库中的敏感数据加密存储数据库审查
□ 密钥管理密钥不硬编码在代码中,使用 KMS配置审查
□ 备份加密数据库备份加密存储配置审查

日志与监控清单

安全日志

检查项检查标准验证方法
□ 认证事件记录所有登录尝试(成功和失败)日志审查
□ 授权事件记录授权失败事件日志审查
□ 敏感操作记录密码修改、权限变更等敏感操作日志审查
□ 请求追踪每个请求有唯一 ID,便于追踪日志审查
□ 日志完整性日志不可篡改,有完整性校验配置审查

监控告警

检查项检查标准验证方法
□ 异常告警认证失败率达到阈值时告警监控测试
□ 流量异常请求量异常波动时告警监控测试
□ 错误率监控API 错误率异常时告警监控测试
□ 性能监控API 延迟异常时告警监控测试

基础设施安全清单

API 网关

检查项检查标准验证方法
□ 统一入口所有 API 请求经过网关架构审查
□ SSL 终止网关处理 SSL 终止配置审查
□ 请求验证网关进行基本请求验证配置审查
□ IP 黑名单支持 IP 黑名单配置审查

容器与部署

检查项检查标准验证方法
□ 非 root 运行容器以非 root 用户运行配置审查
□ 只读文件系统容器使用只读文件系统配置审查
□ 资源限制容器设置 CPU/内存限制配置审查
□ 镜像扫描使用可信来源的镜像,定期扫描漏洞流程审查

密钥管理

检查项检查标准验证方法
□ 不硬编码密钥代码中不存在密钥硬编码扫描审查
□ 环境变量密钥通过环境变量或密钥管理服务注入配置审查
□ 密钥轮转支持密钥轮转,不中断服务功能测试
□ 密钥审计记录所有密钥访问日志审查

错误处理清单

错误响应

检查项检查标准验证方法
□ 统一格式所有错误响应使用统一格式代码审查
□ 错误码使用应用级错误码,不使用 HTTP 状态码描述代码审查
□ 用户友好错误消息对用户友好,不暴露内部细节功能测试
□ 详细日志详细错误信息只记录在服务端日志日志审查

异常处理

检查项检查标准验证方法
□ 全局处理所有未捕获异常由全局处理器处理代码审查
□ 不暴露堆栈生产环境不返回异常堆栈配置审查
□ 数据库错误数据库错误不直接暴露给客户端代码审查
□ 超时处理所有外部调用有超时设置代码审查

HTTP 状态码

检查项检查标准验证方法
□ 正确使用200 成功,201 创建,400 客户端错误,401 未认证,403 无权限,404 不存在,500 服务错误代码审查
□ 不使用 200错误不使用 200 状态码返回代码审查

数据保护清单

个人信息

检查项检查标准验证方法
□ 收集最小化只收集业务必需的个人信息架构审查
□ 目的告知明确告知用户信息收集的目的合规审查
□ 删除权利支持用户请求删除个人信息功能测试
□ 数据保留有明确的数据保留期限和删除策略流程审查

数据脱敏

检查项检查标准验证方法
□ 测试数据测试环境使用脱敏数据,不使用生产数据流程审查
□ API 响应API 响应中的敏感数据经过脱敏处理功能测试
□ 日志数据日志中的敏感数据经过脱敏处理日志审查

变更管理清单

部署安全

检查项检查标准验证方法
□ 代码审查所有代码变更经过审查流程审查
□ 安全测试变更上线前经过安全测试流程审查
□ 回滚计划有变更回滚计划流程审查
□ 灰度发布高风险变更使用灰度发布流程审查

依赖管理

检查项检查标准验证方法
□ 依赖清单维护第三方依赖清单流程审查
□ 漏洞扫描定期扫描依赖漏洞自动化扫描
□ 版本更新依赖版本及时更新流程审查
□ 许可证审查依赖许可证合规法律审查

配置管理

检查项检查标准验证方法
□ 环境隔离开发、测试、生产环境隔离架构审查
□ 配置验证配置变更经过验证流程审查
□ 敏感配置敏感配置加密存储配置审查

完整性检查脚本

security-checklist.sh
#!/bin/bash

# API 安全清单自动检查脚本

echo "=== API 安全清单检查 ==="
echo ""

# 1. 检查 HTTPS 配置
echo "[1] 检查 HTTPS 配置..."
if curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health | grep -q "200"; then
    echo "✓ HTTPS 正常"
else
    echo "✗ HTTPS 配置异常"
fi

# 2. 检查安全响应头
echo ""
echo "[2] 检查安全响应头..."
HEADERS=$(curl -sI https://api.example.com/health)
if echo "$HEADERS" | grep -qi "X-Frame-Options"; then
    echo "✓ X-Frame-Options 已配置"
else
    echo "✗ X-Frame-Options 未配置"
fi

if echo "$HEADERS" | grep -qi "X-Content-Type-Options"; then
    echo "✓ X-Content-Type-Options 已配置"
else
    echo "✗ X-Content-Type-Options 未配置"
fi

# 3. 检查认证端点
echo ""
echo "[3] 检查认证端点..."
if curl -s -o /dev/null -w "%{http_code}" -X POST https://api.example.com/auth/login \
    -H "Content-Type: application/json" \
    -d '{"username":"invalid","password":"wrong"}' | grep -q "401"; then
    echo "✓ 错误认证返回 401"
else
    echo "✗ 错误认证未返回 401"
fi

# 4. 检查 SQL 注入防护
echo ""
echo "[4] 检查 SQL 注入防护..."
PAYLOAD="' OR '1'='1"
RESPONSE=$(curl -s "https://api.example.com/api/users?id=${PAYLOAD}")
if echo "$RESPONSE" | grep -qi "error\|exception\|sql"; then
    echo "✗ 可能存在 SQL 注入(错误信息泄露)"
else
    echo "✓ 未检测到 SQL 注入"
fi

# 5. 检查 CORS 配置
echo ""
echo "[5] 检查 CORS 配置..."
CORS=$(curl -sI -X OPTIONS https://api.example.com/api/users \
    -H "Origin: https://evil.com" | grep -i "Access-Control")
if echo "$CORS" | grep -qi "allow-origin.*\*"; then
    echo "✗ CORS 允许所有来源(不安全)"
else
    echo "✓ CORS 配置合理"
fi

echo ""
echo "=== 检查完成 ==="

思考题

问题 1:在实施安全清单时,如何平衡「检查项的全面性」和「团队的执行成本」?

参考答案

分层实施策略:

  1. 分级清单:将清单分为「必须通过」和「建议检查」两级

    • 「必须通过」:高危漏洞、严重合规问题
    • 「建议检查」:最佳实践、改进建议
  2. 自动化优先:

    • 可自动化的检查项(安全头、TLS 配置等)交给 CI/CD
    • 需要人工的检查项(代码审查、架构审查)安排专门时间
  3. 增量实施:

    • 不要求一次性完成所有检查
    • 每月增加 2-3 个检查项
    • 优先检查风险最高的项

建议的优先级顺序:

  1. 认证与授权(最高风险)
  2. 输入验证(SQL/NoSQL 注入)
  3. 敏感数据保护
  4. 错误处理
  5. 日志监控
  6. 其他

问题 2:如何确保团队持续遵守安全清单,而不仅仅是在审计前临时抱佛脚?

参考答案

技术手段:

  1. 自动化检查集成到 CI/CD:

    • 代码提交时自动运行 SAST 扫描
    • 部署前自动检查配置
    • 合并前检查依赖漏洞
  2. 质量门禁:

    • 将安全检查设为 PR 合入的必须条件
    • 高风险漏洞阻断部署

流程手段:

  1. 安全清单可视化:

    • 使用安全仪表盘展示检查状态
    • 每周安全周报展示改进情况
  2. 责任到人:

    • 每个检查项指定负责人
    • 定期 review 检查项覆盖情况
  3. 激励机制:

    • 发现高危漏洞给予奖励
    • 安全零事故的团队给予表彰

文化手段:

  1. 安全培训:

    • 定期安全意识培训
    • 安全事件案例分享
  2. 安全champion:

    • 每个团队培养安全 champion
    • Champion 负责推动安全实践