Firebase 瀏覽器金鑰未設限遭濫用，Gemini API 呼叫導致 13 小時內帳單暴增 5.4 萬歐元

背景

這起事件源於一名開發者在 Firebase 專案中使用了未設定 API 限制的瀏覽器金鑰，導致該金鑰被惡意利用於呼叫 Gemini API。在短短 13 小時內，帳單金額迅速飆升至 5 萬 4 千歐元，引發了開發者社群對於雲端服務計費安全與防護機制缺失的激烈討論。

社群觀點

針對這起天價帳單事件，Hacker News 社群展現了極大的憤慨與無奈。許多討論集中在 Google Cloud Platform (GCP) 缺乏「硬性預算上限」的設計缺陷。留言者指出，目前 GCP 僅提供預算通知，但通知往往存在數小時的延遲，這在生成式 AI 時代顯得極其危險。Gemini API 的高昂單次呼叫成本，使得原本在 Google Maps 時代可能只會造成數百美元損失的金鑰洩漏，在短短幾分鐘內就能演變成數萬美元的災難。社群普遍認為，Google 身為機器學習領域的領導者，卻無法在系統中識別出這種異常流量並自動限流，甚至將此視為一種獲利模式，實在令人難以接受。

關於 API 金鑰的安全性，社群內部出現了不同的聲音。部分開發者認為 Firebase 金鑰在設計上本就是「客戶端可見」，安全性應建立在嚴格的 API 限制（如網域限制或特定 API 存取權）之上。然而，也有人反駁，Google 在推廣 AI Studio 時，甚至在官方文件中建議了一些缺乏保護的代理方式，這無疑是在誤導開發者。更有留言者直言，API 金鑰這種認證方式已經過時，或許應考慮即時加密支付等替代方案，但隨即遭到反對，認為這會大幅增加開發門檻並造成生產環境的不穩定。

此外，社群對 Google 的處理態度感到失望。有觀點認為這是 Google 史上最嚴重的安全隱患之一，因為他們為了不破壞現有的客戶工作流，選擇不主動修復或強制限制，僅在深層文件中放置微小的警告。開發者們感嘆，在現行的雲端服務體系下，使用者必須自行承擔極高的風險。雖然可以透過 Pub/Sub 結合 Cloud Function 來實作自動關閉專案的機制，但這種做法極其複雜且非預設功能，對大多數初創企業或獨立開發者來說門檻過高。這種「先扣款、後解釋」的模式，正讓越來越多開發者對按量計費的雲端服務失去信心。

延伸閱讀

• 留言中提到 Google AI Studio 的 Build Mode 範例程式碼存在安全風險，相關討論可參考 GitHub 上的 qudent 儲存庫。
• 針對如何透過 Pub/Sub 與 Cloud Function 實作 GCP 帳單硬上限，社群建議參考相關的技術實作教學。