← 回到學習日誌 Back to Journal

API Key 不是設定,是權限An API Key Is Not a Setting. It Is Access.

一次事件後的 30 分鐘安全盤點。A practical 30-minute safety review after a security event.

筆記本檢查清單、實體鑰匙與電腦的安全盤點桌面
01 找出 key 曾出現的地方Find every place a key may have appeared 02 有疑慮就撤銷並重建Revoke and rotate when in doubt 03 設上限、通知與輪替日期Set limits, alerts, and a rotation date
中文版 Chinese version

API Key 是權限,不只是設定

看到一則雲端平台的資安事件後,我做了一次很基本但很值得的檢查:網站裡有沒有 key?Git 歷史裡有沒有?本機設定檔有沒有被不小心追蹤?

API key 不只是串接服務的一行文字,它更像一把權限鑰匙。若被貼進公開 repository、截圖、文件、前端程式,或留在第三方平台的環境變數裡,就可能被用來呼叫服務、消耗額度,甚至接觸資料。

這篇不是要製造焦慮,而是整理一個每個人都能照著做的第一輪檢查。

先做這三件事

  1. 找出 key 曾經出現在哪裡。分開檢查公開網站原始碼、Git repository 與提交歷史、本機 .env、雲端平台環境變數、筆記與螢幕截圖。不要只看現在的檔案,因為刪掉的 key 仍可能留在 Git 歷史裡。
  2. 有疑慮就輪替,不要等待「確定外洩」。若 key 曾放進公開 repo、發生事件的第三方平台,或你無法確認是否被看過,最乾淨的作法是撤銷舊 key、建立新 key,再停用舊的。
  3. 補上使用上限與通知。為付費 API 設預算或用量上限、開啟異常通知、停用不需要的自動儲值,並定期看 usage log。它們不能阻止外洩,但能讓損失不要一路放大。

不要把 key 放在這些地方

真正需要讓瀏覽器使用的服務,應改用後端或 serverless function 代理,由伺服器保管 secret;不要把長期有效的 key 送到使用者瀏覽器。

一份可重複使用的 30 分鐘清單

  1. 列出使用中的 API、token、資料庫與機器人憑證。
  2. 搜尋目前程式碼與完整 Git 歷史是否有真實 key。
  3. 確認 .env 未被追蹤,並檢查 .gitignore。
  4. 檢查所有雲端部署平台中的環境變數。
  5. 對曾暴露或無法確認的 key 執行撤銷與重建。
  6. 設好預算、速率限制與異常通知。
  7. 記錄 key 的用途、負責人與輪替日期,但不要記錄 key 本身。

把輪替變成日常維護

安全不是把工具全部停掉,而是把「方便」和「權限」分開管理。把 key 當成權限,而不是設定;把輪替當成日常維護,而不是事故後才開始的補救。

English version

An API Key Is Access, Not Just Configuration

After reading about a cloud security incident, I did a basic but worthwhile review. Is there a key in the website? In Git history? Is a local configuration file being tracked by mistake?

An API key is more than a line of configuration. It is access. If it appears in a public repository, screenshot, document, frontend bundle, or third-party environment setting, someone may be able to call services, spend a budget, or reach data.

Three Things to Do First

  1. Find every place a key may have appeared. Check source code, Git history, local .env files, cloud settings, notes, and screenshots.
  2. Rotate when there is doubt. Revoke the old key, create a new one, and disable the old credential. Do not wait for proof of exposure.
  3. Set limits and alerts. Use spending limits, rate limits, and unusual-usage notifications to keep an incident contained.

Keep Secrets Out of Public Surfaces

Do not put a long-lived key in frontend code, public JSON, commits, documentation, screenshots, or a real-value example file. Use a backend or serverless function as the proxy when a browser needs to call a service.

Make Rotation Routine

Security is not about stopping useful tools. It is about separating convenience from access. Treat key rotation as normal maintenance, not a panic response.

來源與延伸閱讀 Sources: Zeabur incident notice · Zeabur security best practices
API SecurityCredential HygieneGitCloud SecurityLearning Note