API 密钥泄露之后：暴露面、爆炸半径与吊销顺序
一句话回答
本文从工程实践角度说明 API 密钥泄露的风险来源：密钥可长期重复使用、权限过宽、泄露难以发现。防护重点是把密钥权限收窄、按环境和调用方拆分、缩短有效期并保证可快速吊销；发现泄露后先吊销再排查。文中代码为未执行示例，API.PLUS 的具体字段、吊销生效时间与额度限制未在本次材料中提供，需另行核实。
先给结论：API 密钥泄露的真正风险，不是“有人看到了这串字符”，而是这串字符可以继续用、权限还很大、而且没人知道它已经被复制。因此防护要围绕三件事展开：把单把密钥能做的事变少（缩小影响范围），让它随时可以被作废（可吊销），让异常使用能被看见（可发现）。本文只讨论通用工程实践；API.PLUS 的具体密钥格式、权限粒度、吊销生效时间和限额，本次材料未提供，需要在控制台文档中另行核实。
泄露面往往比开发者以为的更宽#
- 代码与历史：密钥写进源码后提交，即使下一次提交删掉，历史记录里仍然存在，克隆过仓库的人手上都有。
- 构建产物与客户端：打包进前端 JS、移动端安装包、桌面客户端的密钥等同于公开，因为分发即意味着可被提取。
- 日志与错误上报：把完整请求头或 URL 打进日志、上报到第三方平台，是最容易被忽视的一条路径。
- 协作场景：工单、聊天截图、演示环境配置、临时脚本，常常是密钥扩散的实际起点。
- CI 与部署环境：变量注入本身没问题，但如果构建日志会回显变量、或分支构建可被外部触发，就会暴露密钥。
先缩小影响范围，再谈保管#
建议按以下顺序改造，投入产出比最高：
- 最小权限：按调用方分配密钥，一把密钥只对应一类用途；只读与写入分开，能限定来源或范围的就限定。
- 按环境隔离：开发、预发、生产各用各的密钥，测试密钥泄露不应影响生产额度与数据。
- 短期化与服务端中转：能签发临时凭据的场景优先用临时凭据；客户端不应直连持有长期密钥，改为请求自己的服务端转发。是否支持临时凭据取决于服务方能力，待核实。
- 保留可追溯标识：给每把密钥绑定用途和负责人，泄露时才能判断影响范围与通知对象。
存储与使用：环境变量只是起点#
环境变量能避免密钥进入代码库，但它对本机上的任何进程都可见，也会出现在崩溃转储和调试输出中。真正的分界是：密钥不进入代码仓库、不进入客户端产物、不进入日志。下面是一个读取与日志脱敏的写法示例，仅说明思路。
# 未执行示例：仅演示读取位置与脱敏打印，不保证在任意环境可直接运行
import os, logging
API_KEY = os.environ.get("APIPLUS_KEY", "")
if not API_KEY:
raise RuntimeError("缺少 APIPLUS_KEY，应由部署环境注入")
def mask(v: str) -> str:
return "***" if len(v) <= 8 else v[:4] + "***" + v[-2:]
logging.info("prepare call, key=%s", mask(API_KEY))
# 注意：即便脱敏，也应确认日志留存与访问权限符合团队规范
确认泄露后的处置顺序#
常见误区是先查“怎么漏的”。调查可能耗时数小时到数天，而密钥在这段时间里一直可用。建议顺序如下：
- 先吊销或轮换，让旧密钥立即失效；吊销是否即时生效需按服务方说明核实。
- 再评估暴露面：这把密钥能访问哪些资源、有权做什么、从何时起可能外泄。
- 用新密钥恢复服务，新密钥按上面的原则重新设定权限范围。
- 回溯源头：查提交历史、日志、构建配置，确认是单点泄露还是同一模式在多处重复。
- 复核：确认旧密钥已失效、下游无残留引用、监控无异常调用。
一份可复核的自检清单#
| 检查项 | 可复核的判定条件 |
|---|---|
| 代码库无明文密钥 | 对全部历史提交执行密钥扫描，结果为零命中，或命中项均已标记为失效 |
| 客户端产物不含密钥 | 检查打包后的 JS 与安装包，检索不到密钥字符串 |
| 日志已脱敏 | 抽查请求日志、错误上报内容，不出现完整密钥或 Authorization 头原值 |
| 权限已分离 | 每把密钥有用途标注，读写权限不混用 |
| 吊销路径可走通 | 至少演练一次轮换，记录从操作到旧密钥失效的实际耗时 |
本文的边界#
以上是通用实践与建议，不构成对任何具体平台能力的描述。API.PLUS 侧需要确认的信息包括：密钥的权限粒度与作用域、是否支持多密钥并存与自助轮换、吊销的生效时间、是否有调用来源限制与用量异常告警。这些内容本次材料未提供，属于待核实项，建议以官方控制台与文档的实际说明为准，并把核实结果回填到上面的清单里，让每一条都变成可判定、可复查的条件。
