API 密钥安全：泄露发生在哪几处，防护按什么顺序做

API 密钥的风险主要不在“强度不够”，而在于它会随代码、日志、请求和人的操作扩散到服务端之外。防护的落点有三条：不让它出现在客户端；假设它一定会泄露，提前备好轮换路径；真泄露时先吊销、再排查。

密钥通常从哪些位置离开服务端#

• 打包进前端或移动端。浏览器里的一切都可被读取，移动端可被反编译。写进前端代码或前端构建期环境变量的密钥，等同于公开。这是基于部署形态的推断，不针对任何具体平台。
• 进入版本库历史。把当前文件删掉，不等于把提交记录删掉。
• 写进 URL 查询参数。URL 会进入访问日志、浏览器历史、Referer 和中间代理日志。
• 进入日志与错误上报。请求头、异常对象、调试打印都可能带着鉴权信息。
• 进入截图、工单、群聊与录屏。
• 多人共用同一把密钥。出事后无法归属，也无法只吊销其中一个人的权限。

防护的优先顺序#

下面按“减少暴露面 → 限制单点损失 → 保证可恢复”排列，顺序本身就是取舍依据。

1. 密钥只留在服务端

前端调用自己的后端，由后端持有密钥并向第三方发起请求；前端拿到的是自己会话的凭证，而不是第三方的密钥。

如果业务确实需要客户端直连，只能用服务端签发的短期、窄权限令牌。这类机制是否可用取决于服务方是否提供，本次材料没有 API.PLUS 的相关说明，需以其官方文档为准（待核实）。

2. 按环境和用途拆分

生产与测试不共用，读与写不共用，不同项目不共用。这样单把密钥泄露时，影响范围可以被界定。

3. 让轮换路径事前可用

新密钥如何下发、旧密钥何时失效、是否存在并行有效期，都要在出事前跑通一次。没有验证过的轮换预案，实际上等于这把密钥不能吊销。

4. 让日志不记录它

在日志和错误上报的统一入口按字段名过滤（如 authorization、api_key、token 一类），而不是靠每个调用点自觉脱敏。

5. 在仓库侧加拦截

.gitignore、提交前扫描、托管平台的 secret scanning。它们的价值是提早发现，不能替代轮换。

一个服务端代理骨架#

示例只演示“密钥不出服务端”的结构，未执行，也不对应 API.PLUS 的具体端点；请求地址、鉴权头名称与参数需按实际文档替换。环境假设为 Node.js + Express，具体依赖与版本待核实。

// 未执行的示例：仅示意密钥留在服务端
const express = require('express');
const app = express();

const API_KEY = process.env.UPSTREAM_API_KEY; // 从环境变量读取，不写进代码
if (!API_KEY) throw new Error('UPSTREAM_API_KEY is not set');

app.get('/api/proxy/items', async (req, res) => {
  // 这里应先做你自己的身份校验，再决定是否向上游发起请求
  if (!req.user) return res.status(401).json({ error: 'unauthorized' });

  const upstream = new URL('https://api.example.com/v1/items'); // 占位地址
  upstream.searchParams.set('limit', String(Number(req.query.limit) || 20));

  try {
    const r = await fetch(upstream, {
      headers: { Authorization: `Bearer ${API_KEY}` },
    });
    if (!r.ok) return res.status(502).json({ error: 'upstream_failed' });
    res.json(await r.json());
  } catch (e) {
    // 不要把 e 原样返回或整体写进日志，可能带上请求头
    res.status(502).json({ error: 'upstream_unreachable' });
  }
});

app.listen(3000);

注意两点：可透传的参数要白名单化，而不是把客户端 query 整体转发；错误分支不要回传上游响应体原文。

发现泄露后的顺序#

1. 先吊销或轮换，再调查。调查期间密钥仍然有效，等于默认继续泄露。
2. 查使用记录。调用来源、时间窗、异常用量。能查到什么取决于服务方是否提供审计日志（待核实）。
3. 清理暴露点。仓库历史、构建产物、已留存的日志。
4. 回到“它为什么能到那里”。只处理这一次，下一次还会重演。

这些做法的边界#

以上是降低概率、缩短暴露窗口的工程手段，不是保证。它们不能阻止服务端被入侵后密钥被读走，也不能替代服务方的权限模型与配额限制。至于 API.PLUS 的鉴权方式、密钥作用域、是否支持多密钥与调用审计，本次材料未提供，需查其官方文档确认（待核实）。