API 金鑰與密碼放哪：secret 管理入門
金鑰寫進前端或 commit 進 Git 就等於公開。新手該懂的 secret 放法、使用原則，以及外洩了怎麼補救。
屬於路線SaaS 路線
一句話解釋
secret 一旦進到前端或版本控制就等於公開——這篇講該放哪、怎麼用、外洩了怎麼救。
你會做出什麼
知道金鑰 / 密碼該放哪（環境變數 / 平台 secret）、絕不能放哪，以及外洩後的正確補救。
什麼是 secret
Secret 是「不能讓別人看到的鑰匙」：API 金鑰、資料庫密碼、第三方服務的 token、簽章用的密鑰。它們一旦外流，別人就能假冒你、用你的帳單、偷你的資料。所以重點不只是「會用」，更是「藏好」。
絕不能放的地方
- 前端 JavaScript：任何進到瀏覽器的東西，使用者都看得到。前端的 secret＝公開的 secret。
- commit 進 Git：就算之後刪掉，它仍在歷史紀錄裡，等於洩漏。公開 repo 更是被機器人秒掃。
該放哪
- 環境變數 / 平台的 secret 設定：把 secret 放在部署平台（如 Cloudflare）的 secret store 或環境變數，程式從那裡讀，不寫死在程式碼。
- 本機開發用
.env之類的檔案，但一定加進.gitignore、絕不 commit。
這就是業界慣例「設定與程式分離」（12-factor 的 config 原則）：同一份程式碼，換個環境換組 secret 就能跑。
用的原則
- 最小權限：金鑰只給它需要的權限，別都用最大權限的 root key。
- 會過期、能撤銷：盡量用可設效期、可隨時作廢的金鑰，外洩時能止血。
- 不同環境用不同 secret：正式與測試分開，測試外洩不波及正式。
外洩了怎麼辦
立刻 rotate（換掉並作廢舊的）——這是唯一可靠的補救。記住：只要進過前端、進過 Git 歷史、進過聊天記錄或截圖，就視為已洩漏，不要心存僥倖。把舊金鑰作廢、產新的、更新到 secret store。
下一步
- 部署時把 secret 設在平台：部署到 Cloudflare Pages
- 登入系統也大量用到 secret：用 AI 做一個登入系統
常見問題
我不小心把金鑰 commit 進 Git 了，刪掉那行就好嗎？
不夠。刪掉只是讓「現在」看不到，但**它仍留在 Git 歷史紀錄裡**，任何人翻歷史就能拿到，公開 repo 更會被機器人秒掃。唯一可靠的補救是立刻 rotate：把那把金鑰作廢、產一把新的、更新到 secret store。
前端真的不能放任何金鑰嗎？
凡是進到瀏覽器的東西，使用者就能看到——所以「機密」金鑰一律不能放前端。需要呼叫第三方服務時，正解是讓**後端**保管金鑰、由後端代呼叫。少數「本來就公開、權限受限」的金鑰（例如某些只能讀的公開 key）才適合放前端，但仍要在服務端限制它能做什麼。
參考來源
- Secrets Management Cheat Sheet — OWASP
- The Twelve-Factor App — Config — 12factor
SaaS 路線 的下一步: 儲存 →