API key 不小心 commit 了，趕快刪掉，再補一個 commit。做完很容易鬆一口氣，因為現在打開檔案，確實什麼都看不到。偏偏 Git 最擅長的，就是把之前的版本留著。
這個地方有點惱人：你已經發現錯誤，也立刻修正，卻還沒真的把風險處理掉。舊提交裡可能有那把 key，別人也可能早就複製走了。若已經暴露，先去服務提供者那裡撤銷或輪替憑證，讓舊的失效，比一直研究怎麼把那行字擦乾淨更急。
GitHub 在 2025 年 3 月公布 Secret Risk Assessment，預告 4 月 1 日提供給 Team、Enterprise 方案的組織。我覺得它切入的問題滿務實：先別假設大家都把這件事處理好了，掃一次看看。
這項免費評估讓組織或安全管理員查看公開與私人 repository 的機密暴露統計，例如出現了哪些憑證類型、公開可見的數量，以及多少 repo 受到影響。對一個有很多專案的團隊來說，知道問題分布在哪個範圍，至少比逐個問「你們應該沒放吧」可靠。
但我會把它當盤點，不會當成已經有人持續幫忙盯著。它是一次性的彙整報告，不會列出具體 secret；要追到每一把憑證、管理修復進度，還需要 secret scanning 等功能。看到報告沒有列出 key 本身，也不要誤會成什麼都沒找到。
搬到 .env，然後呢？#
聊到這裡，很容易得到一個熟悉的結論：不要寫死在程式，放環境變數。方向沒錯，但中間還有幾個地方會讓人踩空。
.env 要排除在 Git 之外；如果之前已經被追蹤，後來才加 .gitignore 不會讓它從紀錄消失。前端還要多想一步：這個值最後會不會被打包進瀏覽器的 JavaScript？如果會，換個存放位置也沒有把它藏起來。
像能代你寄信、操作付款或管理資料的密鑰，應該留在伺服器端。某些服務原本就提供能放在前端的公開 key，則要看它允許做什麼、服務怎麼設計，不能看到 key 就一律當成同一種東西。
這類新聞沒有很炫的畫面，也不像效能更新能給人一個很快的數字，但我反而覺得值得花點時間看。最尷尬的不是知道有憑證漏出去，是事情真的發生後，才發現沒人知道那把 key 還在哪些地方被使用。到時候連想把它換掉，都得先找人問一圈。