网站里露出了 API 密钥，删掉就够了吗？

变量名说明不了权限

假设一个 AI 写的落地页直接从浏览器调用发信服务，JavaScript 里有个叫 API_KEY 的值。仅凭名字不能判定漏洞。查服务商文档：它是公开标识、受限的客户端密钥，还是能授权操作的机密凭据？不要尝试使用不属于自己的网站凭据。这是示意场景，不是已发生的客户事件。

对于自己的服务，请账号负责人在服务商控制台确认类型和权限。记录受影响脚本的网址与发现时间，不要把完整值复制到邮件、工单或 AI 对话里。用于讨论的截图也应遮住密钥。

先让旧凭据失效，再清理副本

确认机密凭据已暴露后，应尽快与负责人安排撤销或轮换。GitHub 的相关指引也把这一步放在清理仓库历史之前。重新构建页面只消除了一条分发路径，无法阻止别人使用先前下载的副本。

新凭据也要有合适的保存位置。需要机密授权的操作应放到服务端，替换值存入适当的服务端密钥存储。确认构建过程不会再次把它放进浏览器资源；环境变量同样可能被打包到前端。更换期间功能无法安全运行，就商定暂时关闭，不要再发出一把同样暴露的密钥。

账单没涨，也不能直接结案

检查可能暴露期间可获得的调用记录与审计日志，分开写明密钥具备什么权限、日志实际显示了什么。账单平静不能证明数据未被访问，日志缺失应记为核验限制。若证据显示可能存在未授权使用，应交由服务负责人的事件处置流程跟进。

盘点团队能控制的副本：线上脚本、CDN 缓存、代码仓库、构建产物和共享排障资料。清理仓库历史需要与协作者协调；改写历史会影响他人工作，也擦不掉别人的克隆。事件记录应限制访问，并去掉机密值。

改完之后验什么

在自己的已授权账号下确认旧凭据已撤销，新凭据只保留必要权限。检查正式部署的浏览器资源不再包含机密，再确认原本的正常功能可用。记录部署编号与验证时间，不要为了演示影响而产生第三方费用。

外部网站检查可能发现可见凭据，但服务商日志调查、轮换、源码审查和事件响应属于另外的工作。Mingxi 标准公网检查不包含这些工作，也不能证明泄露的密钥从未被使用。交接时保留尚未核实的部分。

执行清单

• 与服务商及负责人确认密钥类型。
• 尽快撤销或轮换确认暴露的机密凭据。
• 核对可用日志，证据中隐藏机密值。
• 验证新部署与原本的正常功能。

常见问题

JavaScript 里出现的密钥都要删除吗？

不一定。有些服务的客户端密钥设计上就是公开的，应遵守该服务对权限和限制的要求。可公开标识与服务端机密凭据不能混为一谈。