如何修复泄露的API密钥：开发者Git安全指南
内容提要
API密钥泄露到Git仓库是常见且严重的安全问题。本文提供了一套完整的应急处理指南，核心步骤为：立即撤销或轮换泄露的密钥、调查可疑活动、从代码和Git历史中移除密钥、替换新密钥并限制其权限，以及通过环境变量、密钥扫描工具和Git钩子等预防未来泄露。文章强调，一旦密钥被提交，必须视为已泄露，即使删除也需彻底清理历史记录。
延伸解读
泄露后的首要行动：撤销而非删除
许多开发者发现密钥泄露后的第一反应是删除文件并提交新版本，但这样做并不安全。Git会保留历史记录，即使删除当前文件，旧版本中的密钥仍可能被自动化工具扫描到。正确的做法是立即撤销或轮换密钥，使其失效，然后再进行清理。这就像钥匙掉在街上，换锁比删除照片更重要。
Git历史清理的适用场景
并非所有泄露都需要重写Git历史。如果密钥从未提交，或仅存在于本地未推送的提交中，通常无需重写。但一旦推送到远程仓库，尤其是公开仓库，就必须视为已泄露，并考虑清理历史。清理前应备份仓库，使用git filter-repo等工具，并验证清理效果。注意，重写历史会改变提交哈希，影响协作者，需谨慎协调。
前端密钥的误区与正确做法
前端代码运行在用户设备上，任何嵌入的密钥都可能被用户通过开发者工具或网络请求查看。有些服务提供专门用于浏览器的公开密钥，但仍需限制域名、配额等。真正的私有密钥绝不能放在前端代码中，而应通过后端代理请求，由后端持有密钥并转发请求，前端只与自己的后端通信。
预防措施：扫描与钩子
除了事后处理，预防同样重要。可以使用Gitleaks、TruffleHog等工具进行密钥扫描，集成到CI流程中，或通过Git钩子在提交前检查。同时，养成提交前审查暂存区（git diff --cached）的习惯，避免误提交.env等文件。这些措施能有效减少密钥泄露的风险。
Q&A
API密钥泄露到Git仓库后，第一步应该做什么？
立即撤销或轮换泄露的密钥，使其失效。这是最重要的第一步，因为即使删除文件，密钥也可能已被复制。
为什么删除Git中的API密钥文件还不够？
因为Git会保留文件的历史版本，即使删除了当前文件，密钥仍然存在于历史提交中，可能被自动化扫描器发现。
如何检查API密钥是否仍在Git历史中？
可以使用命令 `git log --all -S"your-leaked-key" --oneline` 搜索历史提交中的密钥值，或者使用 `git log --all -- config.js` 查看文件历史。
如何从Git历史中彻底移除泄露的密钥？
可以使用 `git filter-repo` 工具，例如 `git filter-repo --path .env --invert-paths` 删除整个文件，或使用 `git filter-repo --replace-text replacements.txt` 替换密钥值。操作前应备份仓库。
如何防止API密钥再次泄露到Git仓库？
使用环境变量或 .env 文件存储密钥，并将 .env 添加到 .gitignore；使用密钥扫描工具（如Gitleaks）和Git钩子；提交前检查暂存区内容。
前端应用中能否安全地存储API密钥？
不能存储私密密钥，因为前端代码对用户可见。应使用公开的浏览器密钥（需限制域名和权限），或通过后端代理请求，将私密密钥保存在服务器端。
泄露的API密钥在什么情况下需要重写Git历史？
如果密钥已推送到远程仓库，尤其是公开仓库，通常需要重写历史。如果仅本地提交未推送，可以清理后推送。如果从未提交，则无需重写。
API密钥泄露后，如何调查可疑活动？
检查服务提供商的日志和仪表盘，寻找请求激增、异常位置、新资源创建、权限变更等迹象，并检查账单。记录时间线有助于分析。
