一个常见的深夜场景
想象一下:你加班到很晚,代码终于跑通了,准备推送到 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 密钥都同样敏感。有些服务会提供浏览器密钥,这些密钥本来就会暴露给用户,但它们仍然应当设置适当的限制、配额和权限。
一条通用规则是:如果某个凭据能够访问私有数据、创建资源、修改记录或产生费用,就不应该直接存放在源代码里。
紧急响应:先做什么
发现凭据泄露时,常见的反应是从文件里删掉密钥,然后再提交一次。不要从这里开始。你的第一优先级是让泄露的凭据失效。
建议按照以下顺序操作:
- 吊销泄露的凭据
- 调查可疑活动
- 从代码中移除秘密
- 用新凭据替换
- 必要时清理 Git 历史
- 验证清理结果
- 增加防止未来泄露的保护措施
可以把 API 密钥想象成一把掉在拥挤街道上的房门钥匙。如果已经有人捡走了实体钥匙,删除钥匙的照片并没有意义。应该先换锁。
第一步:吊销或轮换泄露的密钥
前往签发该凭据的服务后台。根据服务不同,后续操作会有所差异,但核心动作是让已经暴露的密钥立即失效,使任何拿到它的人都无法继续使用。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.