💡先搞懂：API 與 API Key 是什麼
API 是程式呼叫服務的櫃台；API Key 則是不必再次輸入密碼，就能代表你的專案使用服務的付費通行證。
API程式櫃台你的應用把文字、圖片或資料送到 endpoint，供應商處理後回傳結果。
KEY門禁卡服務用它辨識專案與權限；持有有效 Key 的人通常能直接送出請求。
$公司簽帳卡Tokens、圖片或語音費用記在 Key 所屬帳戶，不會每次再問信用卡持有人。
這類 Key 常是 bearer credential：誰持有、誰就能用。因此它不是普通設定值，更不能因為 AI 產生的程式「跑得動」就直接上線。
環境變數不是保險箱：它解決「不要把秘密寫進原始碼」，卻不保證代管平台、建置流程、執行中的程式或有權限的 AI agent 永遠讀不到明文。
📅事件時間軸
- 2026 年 8 月 27 日Zeabur 偵測到資安事件並在當日撤銷憑證、封鎖路徑；攻擊者已針對專案環境變數進行查詢。
- 偵測當日團隊撤銷受影響的內部憑證、封鎖該存取路徑，並表示事件在同一天受到控制。
- 2026 年 8 月 28 日 07:11 UTC官方狀態頁公開事件、確認暴露的變數名稱與使用者輪替建議。
- 2026 年 8 月 29–30 日官方確認攻擊者利用外洩的高權限 AWS 管理憑證進入東京共享叢集，再取得通往主要資料庫的內部連線；查詢模式顯示 AI Key 與可直接使用的憑證是主要目標。
- 2026 年 8 月 30 日Zeabur 表示已收到大量未授權使用與賠償申請，約 63% 已核實、21% 審查中，其餘需要補件。
- 調查持續中官方表示完整事故報告將在內部調查與第三方鑑識完成後公布，內容會包含完整時間線、根因、確認影響範圍與長期改善。
🧰受災現場：別人呼叫，你的帳單上升
API 被盜用不一定會先出現「有人登入你的帳號」。攻擊者只要帶著有效 Key 呼叫上游服務，就可能消耗 tokens、額度或自動加值；真正的持有人往往先從用量尖峰、信用卡通知或額度耗盡發現。
大量官方收到未授權使用申報Zeabur 未公布總人數與總損失，因此不能自行推算。
63%已核實並進入賠償處理這是申請案件的處理比例，不等於所有使用者的受害率。
21%仍在審查其他案件需要補上時間、金額、用量或來源等佐證。
當事人公開自述：有工程師表示凌晨先收到信用卡異常止付，短時間 API token 扣款衝到平常單日用量近十倍。這是受災情境，不是可用來推算總額的統計資料。
Zeabur 官方列出 26 個確認暴露的環境變數名稱。即使改了變數名，只要值符合 AWS、GitHub、Anthropic、OpenRouter、OpenAI 或 Stripe 可辨識的憑證格式，也在確認暴露範圍內。
| 類型 | 代表值 | 可能後果 | 第一動作 |
|---|---|---|---|
| AI API | OpenAI、Anthropic、OpenRouter | 付費額度遭盜用、異常用量與帳單 | 撤銷舊 Key、建立新 Key、查用量 |
| 雲端與 Git | AWS、Cloudflare、GitHub Token | 能做什麼取決於該憑證實際權限 | 撤銷後依權限追查資源與紀錄 |
| 資料庫 | DATABASE_URL、MongoDB、Postgres | 可能連入資料庫；還受帳號權限與網路限制影響 | 輪替帳密並檢查查詢、連線與稽核紀錄 |
| 應用程式 | JWT_SECRET、Private Key | 可能偽造簽章或冒用服務身分 | 輪替並評估既有 Token 是否必須失效 |
🔍Vibe Coding 為什麼特別容易漏 Key？
AI 能很快產生「會動的 Demo」，卻不知道你的 Key 是否有付費權限、部署環境是否公開，或團隊是否有事故處理能力。若人只驗證功能、不審查信任邊界，舊式的秘密管理錯誤就會被高速複製。
1要求 AI 串接服務Prompt 只說「接 OpenAI」，沒說 Key 必須留在後端
2秘密進錯位置前端環境變數、JavaScript、README、對話或 agent 設定檔
3未審查就部署程式能跑便上線，忽略 bundle、Git history、log 與工具權限
4掃描後直接濫用Key 是可立即使用的 bearer credential，帳單記在原帳戶
前端不存在秘密：
VITE_*、NEXT_PUBLIC_* 或打包進 App 的值，都會交到使用者裝置。正確做法是「瀏覽器 → 你的後端 → AI 供應商」，付費 Key 只留在後端。研究依據：Wiz：AI 時代的有效秘密外洩研究、Wiz：Vibe-coded apps 常見風險、Vite 環境變數文件
⚖️API 金鑰正確使用守則
✅ 一定要做
- 每個專案、每個環境、每種用途使用不同 Key。
- 只在後端或 Secret Manager 保存，限制模型、API、來源 IP 與權限。
- 設定真正會拒絕請求的硬上限，另外再設多段用量警報。
- 記錄 Owner、用途、建立日、最後使用日與撤銷方式。
⛔ 不可這樣做
- 不可專案共用同一把 Key，也不要讓 dev、test、production 共用。
- 不要放進前端、公開 Repo、截圖、客服工單或 AI 對話。
- 不要把「寄信提醒的軟預算」誤認為會停機的硬上限。
- 個人實驗不要開無限制自動加值；優先預付或手動加值。
上限非常重要：先確認供應商提供的是「警報／軟預算」還是「達標後拒絕請求的硬上限」。例如 OpenAI 的專案 monthly spend limit 是軟性門檻，超過後請求仍可能繼續；不能只設一封通知信就以為已止損。（OpenAI Projects 官方說明、OpenRouter Guardrails）
加值策略：個人學習、Demo 與短期 Vibe Coding 專案，優先選擇小額預付、手動加值並關閉自動加值。若正式營運必須自動補值，也要搭配每把 Key 的硬上限、速率限制與有人處理的警報。（Anthropic 預付與自動補值說明）
🧭互動：這個 API Key 放法安全嗎？
Vibe Coding 金鑰快篩
判斷前端、共用 Key、預算與 Secret Manager 情境；選出最需要的處置。
題目：1／6答對：0
🚨互動：六步緊急止血
輪替不是「新增一把」而已。正常維護可採「建立新 Key → 更新部署 → 驗證新 Key → 撤銷舊 Key」以免服務中斷；若舊 Key 正在被盜刷，則要優先撤銷舊 Key 止血，再恢復服務。
憑證輪替演練
點擊每一步切換狀態；也可以用 Tab 聚焦，再按 Enter 或空白鍵。
已完成：0 / 6
尚未止血：先從撤銷舊憑證開始，避免它繼續被使用。
最常見的錯誤：建立新金鑰、把新值填回平台，卻忘了在上游服務撤銷舊金鑰。建立新 Key 不會讓舊金鑰自動失效；攻擊者手上的舊值仍然有效。
🛡️安全基線：上線前逐項打勾
✂️一專案、一環境、一把 Key
每個專案獨立，dev、test、production 也拆開；人員之間不可共用個人 Key。
每個專案獨立，dev、test、production 也拆開；人員之間不可共用個人 Key。
🖥️付費 Key 只留後端
Browser／App 只帶自己的 session；後端從 Secret Manager 取 Key，再代呼叫 AI。
Browser／App 只帶自己的 session；後端從 Secret Manager 取 Key，再代呼叫 AI。
🧱設定硬上限與速率限制
選擇達標後會拒絕請求的 cap，並限制可用模型、endpoint、來源 IP 與每分鐘請求。
選擇達標後會拒絕請求的 cap，並限制可用模型、endpoint、來源 IP 與每分鐘請求。
🔔多段用量警報
在 50%、80%、90% 或異常尖峰通知會處理的人；警報是偵測，不是停止扣款。
在 50%、80%、90% 或異常尖峰通知會處理的人；警報是偵測，不是停止扣款。
💳小額預付、手動加值
實驗專案關閉自動加值；正式服務若必須開啟，也要限制單次與每月可補金額。
實驗專案關閉自動加值；正式服務若必須開啟，也要限制單次與每月可補金額。
🔎提交前掃秘密
.env* 加入忽略清單，啟用 pre-commit、CI secret scanning 與 GitHub push protection。官方做法：OpenAI API Key Safety、Google Gemini API Key 指引、GitHub 外洩秘密處置
🎯重點整理
🪪Key 是付費身分
持有者可以代表專案呼叫 API，費用通常由原帳戶承擔。
持有者可以代表專案呼叫 API，費用通常由原帳戶承擔。
📦Variables 不是 Vault
它只是注入方式；正式環境仍要保護保存、讀取與記錄路徑。
它只是注入方式；正式環境仍要保護保存、讀取與記錄路徑。
✂️Key 絕不跨專案共用
拆分 Owner、用途與環境，才能單獨限制、追查與撤銷。
拆分 Owner、用途與環境，才能單獨限制、追查與撤銷。
🗑️新舊都要處理
建立新金鑰不會讓舊金鑰自動失效；換新後一定要撤銷舊 Key。
建立新金鑰不會讓舊金鑰自動失效；換新後一定要撤銷舊 Key。
🚧硬上限才會擋
軟預算與用量警報只負責通知，不等於供應商會停止請求。
軟預算與用量警報只負責通知，不等於供應商會停止請求。
💳控制可花金額
個人實驗優先手動加值；正式服務才在硬上限保護下評估自動加值。
個人實驗優先手動加值；正式服務才在硬上限保護下評估自動加值。
❓自我檢測
Q1. API Key 為什麼不能當成普通設定值？
它是代表專案呼叫服務的付費憑證。持有有效 Key 的人通常不必再登入，就能消耗額度或使用它被授予的權限。
Q2. 建立一把新的 OpenAI API Key 後，舊 Key 會自動失效嗎？
不會。正常輪替要部署並驗證新 Key，再到上游服務明確撤銷舊 Key；若正被盜刷，應優先撤銷舊 Key 止血。
Q3. 設定 monthly budget，就等於有硬性用量上限嗎？
不一定。許多 budget 或 spend limit 只是軟預算與警報，超過後請求仍可能繼續。必須確認供應商是否提供達標後拒絕請求的硬上限。
Q4. 為了方便，可以讓多個專案共用同一把 Key 嗎？
不應該。每個專案、環境與用途都要使用不同 Key，才能分開限制費用與權限，並在單一專案出事時局部撤銷。
Q5. 個人 Vibe Coding 實驗應該開啟自動加值嗎？
沒有營運必要時，優先使用小額預付或手動加值並關閉自動加值。這樣即使 Key 外洩，可被消耗的金額也比較有限。
Q6. 把 Key 放在後端環境變數就百分之百安全嗎？
不是。它比前端或原始碼安全，但平台、執行程序與有權限的 agent 仍可能讀取。正式環境還需要 Secret Manager、最小權限、來源限制、稽核與快速撤銷。