REST API 安全检查有哪些关键点？
直接答案
对于一个 REST API，最重要的安全检查涵盖五个方面：(1) 真实性下载验证，(2) 凭据管理，(3) 权限与授权，(4) 更新与补丁，(5) 备份与恢复。这些检查可降低客户端与错误代码通信、密钥泄露、用户越权访问数据，或已知漏洞被利用的风险。
机制与定义
REST API 是一种基于 HTTP 的接口，客户端通过调用特定端点（例如读取或写入数据）进行交互。安全检查是确保以下内容的控制措施：你运行的代码是真实的，请求经过身份验证（谁在调用），操作已获授权（调用者可执行哪些操作），以及系统能在故障中存活。
以下是实用的心理模型：
- 真实性下载：确保软件制品（应用程序代码、客户端 SDK、库、容器）来自可信来源且未被篡改。
- 凭据：保护用于身份验证的令牌、API 密钥、证书和会话密钥。
- 权限：在每一层（API 网关、应用程序、数据库）实施最小权限原则，防止一个账户访问所有资源。
- 更新：保持 API 及其依赖项为最新版本，并安全验证变更。
- 备份：确保在数据损坏、配置错误或安全事件后，能够恢复数据和系统行为。
实际检查清单（含假设）
以下是一个自包含的检查清单。假设条件为：无实时市场数据、不保证结果，且不同提供商的行为可能不同。
1) 真实性下载（验证）
- 使用加密校验（如发布方的校验和或数字签名）验证下载内容。
- 跟踪所安装依赖项的版本及其来源（可复现的构建有助于此过程）。
- 警告标志：未签名的制品、“latest”下载未锁定版本，或从不可信镜像拉取的依赖项。
2) 凭据（密钥管理）
- 将密钥存储在源代码之外（如环境变量或密钥管理器）。
- 使用最小权限凭据：尽可能为读取和写入操作使用不同的密钥。
- 在密钥泄露或定期轮换时更新凭据。
- 警告标志：密钥硬编码在代码中、日志、错误消息或 CI 输出中。
3) 权限与授权
- 使用强身份验证（例如基于令牌的身份验证），并为每个端点实施授权检查。
- 确保角色/属性检查在服务器端强制执行，而不仅依赖客户端。
- 通过审查验证：确认“读取”端点无法通过参数更改升级为“写入”操作。
- 故障模式：授权漏洞导致客户端可访问其他租户或用户资源。
4) 更新与补丁
- 维护已部署版本的清单（API 服务、中间件、库、TLS 设置）。
- 当所运行组件的关键漏洞被披露时，立即打补丁。
- 实施回滚机制：在更新导致功能中断时能够恢复。
- 警告标志：长期使用的“冻结”镜像、缺乏变更跟踪，或未测试升级路径。
5) 备份与恢复
- 以可一致恢复的方式备份数据和配置。
- 测试恢复流程（无法恢复的备份即为风险）。
- 记录并定期演练恢复流程。
- 故障模式：备份仅恢复部分状态，或敏感数据的备份与生产系统具有相同的暴露控制。
需考虑的局限性与风险
- 提供商和环境差异很重要：检查清单并非万无一失，因实现方式各异。
- 过时文档可能误导：部署后安全假设可能已过时。
- 历史关系不保证未来结果；威胁不断演变，漏洞可能以新形式重现。
- 实质性限制：即使控制正确，配置错误、密钥泄露或授权缺陷仍可能导致暴露。
验证与后续问题
自我验证的“清晰标准”是，你能否回答以下关于自身 REST API 配置的问题：
- 你如何证明下载的制品是真实的？
- 凭据存储在哪里？谁可以访问？如何轮换？
- 每个端点应用了哪些授权规则？如何测试？
- 你的补丁时间表和回滚计划是什么？
- 你能否在受控测试中从备份恢复？恢复访问权限是否适当受限？
如果你愿意，可分享你的高层架构（不含密钥），例如认证在何处实施、部署如何进行，我可以帮助将此检查清单转化为定制化的控制审查。