API 密钥安全：泄露面、四道防线与泄露后的处置顺序

结论先说：API 密钥泄露的高发环节，在于密钥被复制到不该出现的地方，而非服务器被攻破——前端包体、仓库历史、日志、截图、CI 配置都是常见位置。防护顺序应当是：先让密钥不出服务端，再谈最小权限、轮换与检测。

一、先划清泄露面#

下面这些位置有一个共同点：密钥会随代码、流量或排障材料扩散出去，而不是留在受控的进程里。

• 浏览器与移动端包体：打包进 JS 或 App 的密钥，抓包、查看 source map 或反编译即可获得。
• 公开仓库与提交历史：删除当前文件不等于删除历史，fork 与缓存也可能保留。
• 日志与错误上报：完整记录请求头的日志系统，会把 Authorization 一起收走。
• URL 查询串：出现在访问日志、代理日志和 Referer 中，扩散面比请求头大。
• CI/CD 变量与脚本：调试时打印环境、把变量拼进命令行，都可能留下副本。
• 工单、聊天与截图：排障时贴出的配置片段，往往没人回收。

二、四道防线，按性价比排序#

1. 密钥不进客户端：前端调用自家后端，由后端持有密钥并访问上游 API。后端同时承担用户鉴权、限流与调用审计，这是把密钥从“不可控环境”挪回“可控环境”的关键一步。
2. 最小权限与分环境：测试与生产各用一把，只授予必要的能力与额度。一把密钥打通所有环境，等于把测试环境的疏漏直接放大到生产。
3. 可观测、可吊销：能查到某把密钥被谁、在什么时间、从哪个来源使用，才能在异常时快速定位。平台是否提供子密钥、IP 白名单、用量告警，以及吊销后的生效延迟，待核实，应按其官方文档确认。
4. 扫描与脱敏：提交前扫描、日志写入前过滤请求头、错误上报前剔除凭据字段。这一步不阻止泄露发生，但能显著缩短“泄露到发现”的窗口。

三、示例：把密钥从前端移走#

以下代码为说明职责划分的示意片段，未实际执行，域名与密钥均为占位。

不推荐：密钥随页面下发，任何打开开发者工具的人都能看到。

// 反例：浏览器直接携带密钥
fetch("https://api.example.com/v1/chat", {
  method: "POST",
  headers: { Authorization: "Bearer YOUR_API_KEY" }
});

推荐：浏览器只调用自己的后端，密钥在后端注入。

// 前端（示意，未执行）
fetch("/api/chat", { method: "POST", body: payload });

// 后端（示意，未执行）：密钥来自服务端环境，不下发
app.post("/api/chat", async (req, res) => {
  // 先校验登录态与配额，再转发
  const upstream = await fetch("https://api.example.com/v1/chat", {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.API_KEY}` },
    body: JSON.stringify(req.body)
  });
  res.status(upstream.status).send(await upstream.text());
});

四、确认泄露后的处置顺序#

1. 先吊销，再改代码。代码修复不会让已流出的密钥失效。
2. 查调用记录：确认异常调用的时间窗、来源与消耗，判断影响面。
3. 清理暴露位置：移除包体中的密钥、清理历史提交中的凭据、修正日志记录方式；同时把已暴露的那把密钥视为永久失效。
4. 复盘引入环节：是缺少扫描、缺少评审，还是排障流程要求贴配置，再针对性补规则。

五、边界：本文能说到哪#

本文讨论的是通用工程实践，未联网核验任何平台的当前策略。API.PLUS 是否提供密钥分级、子密钥、IP 白名单、用量告警，以及轮换后的生效时间与历史调用查询能力，均待核实，应以官方文档与实际控制台为准。不要把上面的清单直接当成某个产品的配置说明：先确认平台具备哪些机制，再决定哪些环节需要自建。