網站露出了 API 金鑰，刪掉就夠了嗎？

變數名稱說明不了權限

假設 AI 寫的到達頁直接從瀏覽器呼叫寄信服務，JavaScript 裡有個叫 API_KEY 的值。僅憑名稱不能判定弱點。查服務商文件：它是公開識別碼、受限用戶端金鑰，還是能授權操作的機密憑證？不要嘗試使用別人網站的憑證。這是示意情境，並非已發生的客戶事件。

對自己的服務，請帳號負責人在服務商控制台確認類型與權限。記錄受影響程式檔的網址與發現時間，不要將完整值貼到郵件、工單或 AI 對話。討論用的截圖也應遮住金鑰。

先讓舊憑證失效，再清理副本

確認機密憑證已暴露後，應盡快與負責人安排撤銷或輪替。GitHub 的相關指引也把這一步放在清理儲存庫歷史之前。重新建置頁面只消除一條分發路徑，無法阻止別人使用先前下載的副本。

新憑證要有合適的保存位置。需要機密授權的操作應放到伺服器端，替換值存入適當的伺服器端機密儲存。確認建置流程不會再次將它放進瀏覽器資源；環境變數也可能被打包到前端。更換期間若功能無法安全運作，就商定暫時關閉，不要再發出一把同樣暴露的金鑰。

帳單沒增加，也不能直接結案

檢查可能暴露期間可取得的呼叫紀錄與稽核日誌，分開寫明金鑰有哪些權限、紀錄實際顯示了什麼。帳單平靜不能證明資料未遭存取；日誌缺失應記為核驗限制。證據若顯示可能遭未授權使用，應交由服務負責人的事件處理流程跟進。

盤點團隊能控制的副本，包括線上程式檔、CDN 快取、儲存庫、建置產物與共享排障資料。清理儲存庫歷史須與協作者協調；改寫歷史會影響他人，也無法抹除別人的複本。事件紀錄應限制存取並移除機密值。

改完之後驗什麼

在自己的已授權帳號下確認舊憑證已撤銷、新憑證只保留必要權限。檢查正式部署的瀏覽器資源不再含機密，再確認原有功能正常。記錄部署編號與驗證時間，不要為展示影響而產生第三方費用。

外部網站檢查可能找到可見憑證，但服務商日誌調查、輪替、原始碼審查與事件應變是另外的工作。Mingxi 標準公網檢查不包含這些工作，也不能證明洩漏金鑰從未被使用。交接時保留尚未核實的部分。

執行清單

• 與服務商及負責人確認金鑰類型。
• 盡快撤銷或輪替確認暴露的機密憑證。
• 核對可用日誌，證據中隱藏機密值。
• 驗證新部署與原有的正常功能。

常見問題

JavaScript 裡的金鑰都要刪除嗎？

不一定。有些服務的用戶端金鑰設計上就是公開的，應遵守服務商對權限與限制的要求。可公開識別碼與伺服器端機密憑證不能混為一談。