一个常见的深夜场景

想象一下：你加班到很晚，代码终于跑通了，准备推送到 GitHub。你依次执行了 git add .、git commit 和 git push。几分钟后，你注意到一些奇怪的现象：API 用量突然上升，可能出现了意外请求、新的云资源，或者账单金额比预期高出一大截。

打开网易新闻 查看精彩图片

随后你发现了问题所在：

const apiKey = "sk_live_123456789";

你的 API 密钥正躺在 Git 仓库里。这种情况确实让人紧张，但并非无法补救。

最要紧的一条规则

如果 API 密钥已经被提交到 Git，就要假定它已经被复制并可能遭到滥用，即使你立刻删除它。只从文件的最新版本里删掉密钥，并不能让旧密钥变得安全。Git 会在历史记录中保留文件的旧版本，而暴露的凭据可能被自动化扫描器发现。

整篇文章会围绕一个基本流程展开：吊销 → 调查 → 移除 → 替换 → 预防。在进入最关键的“密钥暴露后立刻该做什么”之前，先要弄清楚 API 密钥到底是什么。

API 密钥是什么

API 密钥是一种凭据，它允许应用程序与另一个服务通信。例如，一个应用程序可能用 API 密钥访问天气服务、支付提供商、地图服务、人工智能 API、云平台、数据库、邮件服务商或私有公司 API。

密钥可能像这样出现在代码里：

const apiKey = "your-real-api-key";

也可能出现在配置文件中，例如：

{ "apiKey": "your-real-api-key", "databasePassword": "your-real-password" }

API 密钥常被称为“秘密”，因为拥有它的人可能发起请求、访问数据、创建资源，或者在你的账户上产生费用。并非每把 API 密钥都同样敏感。有些服务会提供浏览器密钥，这些密钥本来就会暴露给用户，但它们仍然应当设置适当的限制、配额和权限。

一条通用规则是：如果某个凭据能够访问私有数据、创建资源、修改记录或产生费用，就不应该直接存放在源代码里。

紧急响应：先做什么

发现凭据泄露时，常见的反应是从文件里删掉密钥，然后再提交一次。不要从这里开始。你的第一优先级是让泄露的凭据失效。

建议按照以下顺序操作：

  1. 吊销泄露的凭据
  2. 调查可疑活动
  3. 从代码中移除秘密
  4. 用新凭据替换
  5. 必要时清理 Git 历史
  6. 验证清理结果
  7. 增加防止未来泄露的保护措施

可以把 API 密钥想象成一把掉在拥挤街道上的房门钥匙。如果已经有人捡走了实体钥匙，删除钥匙的照片并没有意义。应该先换锁。

第一步：吊销或轮换泄露的密钥

前往签发该凭据的服务后台。根据服务不同，后续操作会有所差异，但核心动作是让已经暴露的密钥立即失效，使任何拿到它的人都无法继续使用。