前言
晚上好，我是 miruky。
請看這張圖片。
如圖所示，Firebase 官方文件寫明了「Firebase 服務的 API 金鑰不是機密」。或許不需要多作說明，Firebase 是由 Google 提供的行動與 Web 應用程式開發平台。照這個方針，將 API 金鑰嵌入前端 HTML，一直都是 Google 所建議的設計方式。
然而前陣子，某個啟用 Firebase AI Logic 的專案，發生了在 短短 13 小時內產生 €54,000（約 900 萬日圓） 的 Gemini API 帳單。
我覺得這件事非常有「明天可能就輪到我」的感覺，所以想整理成文章分享出來。
原因其實很單純。當你在 GCP 建立 API 金鑰時，預設會處於 可存取所有 API 的「未受限制」狀態。當 Gemini API 啟用的瞬間，原本公開的 Firebase API 金鑰也能作為 Gemini 的驗證資訊使用，於是被攻擊者濫用了。
本文會整理這起事件的背景，以及現在立刻應該採取的對策。之前我也寫過 AWS 因 DDoS（EDoS）造成費用暴增的文章，雲端帳單爆炸其實不分平台，都有可能發生。
目次
- 發生了什麼事
- 原因是 API 金鑰「預設不受限制」
- 現在就該做的對策
- Google 的應對與仍存在的課題
1. 發生了什麼事
受害者擁有一個超過 1 年前為 Firebase 驗證而建立的專案，最近為了新增簡單的 AI 功能（從文字提示生成 Web 程式碼片段）而啟用了 Firebase AI Logic。就在那之後，深夜開始大量湧入惡意請求，最終產生了超過 €54,000 的帳單。
項目內容被害金額€54,000 以上（約 900 萬日圓）發生時間約 13 小時（深夜時段）預算警示已設定為 €80 → 幾小時後才觸發（觸發時已達 €28,000）Google 的回應以「正當使用」為由拒絕調整費用同樣的受害案例也有其他人回報，分別出現了 13,428 美元、82,000 美元等帳單（查一下其實不少）。
下方 Reddit 裡，甚至有人悲痛地表示再這樣下去公司會倒閉。82,000 美元約 1,200 萬日圓，這當然會讓人崩潰……對方顯然也是典型的網路犯罪受害者，似乎還去向 FBI 諮詢了。
回到正題，預算警示之所以來不及發揮作用，是因為 Google Cloud 的計費系統本身存在結構性的延遲。官方文件雖然寫著最多約 10 分鐘，但實際上也有 延遲數小時 才觸發的案例。只靠警示，對這類攻擊本質上是無力的（這不只限於 GCP）。
其實這個問題早在 2025 年 11 月就已由資安公司 Truffle Security 向 Google 的漏洞揭露計畫（VDP）通報。
就是這個，完全就是這次的事件。雖然正式報告日期是 2026 年 2 月 25 日，但報告內提到，Google 早在 11 月就已收到漏洞通報。
事實上，這類事件的客服回信中，幾乎都一定會提到上面 Truffle Security 的報告。
2. 原因是 API 金鑰「預設不受限制」
2-1. 預設可存取所有 API
在 GCP 控制台新建立 API 金鑰時，預設會設定為 「不限制金鑰（Unrestricted）」。這代表它可以存取專案中所有已啟用的 API。
Firebase 的初始化流程不會要求你設定 API 金鑰限制，而 Firebase AI Logic 的教學也常常省略這一步。結果就是，世界上存在著大量「未受限制」的金鑰。
2-2. Gemini 登場後，公開金鑰變成了「驗證資訊」
Google 官方一直都說 Firebase 的 API 金鑰「不是機密」。
Firebase 服務的 API 金鑰不是機密
實際上，這些金鑰本來只是專案識別碼，即使公開也沒問題。然而 Gemini API 會把同樣格式的 AIza... 金鑰當作 驗證憑證 使用。
當你在專案中啟用 Gemini API（Generative Language API）時，該專案內既有的所有金鑰都會變成可存取 Gemini 端點。沒有警告，也沒有確認對話框。Truffle Security 將這種情況稱為 「Retroactive Privilege Expansion（追溯式權限擴張）」。
概念上大概就是這樣，這只是其中一個例子。
攻擊方式其實非常簡單，只要從網站原始碼裡複製出 AIza... 金鑰，然後呼叫下面的指令即可。
curl <span>"https://generativelanguage.googleapis.com/v1beta/files?key=</span><span>$API_KEY</span><span>"</span>
如果回傳 200 OK，就代表這個金鑰有漏洞，請照後面說明進行對策。
2-3. 受害範圍
Truffle Security 在 2025 年 11 月發現了 2,863 個 受此漏洞影響的有效 API 金鑰。裡面甚至包含大型金融機構、資安公司，以及 Google 自己 的金鑰。
持有脆弱金鑰的攻擊者，不只可以濫用計費額度，還能透過 /files/ 與 /cachedContents/ 端點存取上傳到專案中的資料。
3. 現在就該做的對策
以下對策適用於所有在 GCP 專案中使用 Firebase、Google Maps、YouTube 等 任何 Google 服務 的開發者。
3-1. 為 API 金鑰設定 API 限制
這是 最重要的對策。請在 GCP 控制台的 「API 與服務」→「憑證」 中打開各個金鑰的設定，明確指定可存取的 API。
API 限制:
"不限制金鑰" ← 危險（預設）
"限制金鑰" ← 請選這個
允許的 API:
[允許] Firebase Authentication API
[允許] Cloud Firestore API
[排除] Generative Language API ← 要排除
Firebase 用金鑰只應允許 Firebase 相關 API，並且 務必明確排除 Generative Language API。
另外，先確認 「API 與服務」中是否已啟用 Generative Language API 也很重要。若尚未啟用，就不會受到這個漏洞影響。
點進去之後，也可以將其停用。
3-2. 定期輪替 API 金鑰
API 金鑰就算外洩也不容易察覺，因此定期輪替是有效的做法。可以從 GCP 控制台重新產生金鑰。
輪替時，不要立刻刪掉舊金鑰，而是 先讓新舊兩把金鑰並存一段時間 會更安全。等確認所有用戶端都已切換到新金鑰後，再停用舊金鑰。
3-3. 設定使用額上限與預付方案
【使用額上限】
自 2026 年 4 月 1 日起，Gemini API 已套用依等級區分的使用額上限（例如 Tier 1 每月 250 美元、Tier 2 每月 2,000 美元等）。專案層級的上限也可以從 AI Studio 的費用頁面 設定（Beta 版）。
不過，由於 最多有 10 分鐘的處理延遲，仍無法完全阻擋高速攻擊。GCP 的 Quotas（配額） 是即時套用的，因此建議在「IAM 與管理」→「配額」中限制 Generative Language API 的請求數，效果會比較好。
【預付方案】
自 2026 年 3 月 23 日導入的預付方案，會先購買 $10～$5,000 的額度，當餘額歸零時服務就會立即停止。新用戶預設會被分配到預付方案。
如果啟用預付的自動加值，請把加值金額設得低一點。否則在遭受攻擊時，可能會被持續自動補充額度。
3-4. 依用途分離 API 金鑰
不要把同一把金鑰重複用在多種用途上，請依用途分開。
- Firebase 用金鑰：僅限 Firebase Authentication、Firestore 等
- Maps 用金鑰：僅限 Maps JavaScript API，並設定 HTTP referrer 限制
- Gemini API 用金鑰：僅限 Generative Language API，且 只在伺服器端使用
請避免把 Gemini API 金鑰放進客戶端 JavaScript。如果前端必須呼叫，請考慮導入 Firebase App Check。
4. Google 的應對與仍存在的課題
4-1. 迄今為止的經過
我有用 Google 翻譯來翻，所以可能會有一些怪怪的日文翻譯痕跡。
Truffle Security 在 2025 年 11 月回報了這個漏洞，但 Google 一開始以「這是預期行為」為由駁回。後來在對方提出自家基礎設施也會受影響的具體案例後，才終於重新分類為「漏洞」。2026 年 1 月被認定為「Single-Service Privilege Escalation, READ」（Tier 1），而 Truffle Security 於 2 月 25 日在部落格公開了上述細節。
Google 目前正在推進的主要對策有 3 項：
- 導入 Auth Keys（認證金鑰）：提供給新使用者不同於
AIza...的更安全金鑰格式 - 自動封鎖外洩金鑰：自動阻擋已被確認公開的金鑰存取 Gemini API
- 預計停用未受限制金鑰：Gemini 產品負責人表示，正朝著「停用未受限制金鑰使用 Gemini API」的方向前進
4-2. 仍然存在的課題
既有的未受限制金鑰不會因為這些變更就自動變安全。 API 限制仍然需要由專案擁有者自行設定。預算警示延遲的問題也還沒解決，而且雲端計費系統依然沒有真正的硬性上限。
結語
感謝你讀到這裡。
GCP 的 API 金鑰預設為「不受限制」的機制，加上 Gemini API 出現後 AIza... 金鑰又能作為驗證資訊使用，這兩件事疊在一起，才導致公開的金鑰在短短幾小時內產生約 900 萬日圓的帳單。
最重要的對策，就是立刻打開 GCP 控制台確認 API 金鑰的限制設定。也請一併實施金鑰定期輪替、使用額度上限與預付方案設定。
那麼，下次見。
參考連結
事件・漏洞報告
- Unexpected €54k billing spike in 13 hours - Google AI Developers Forum
- €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs - Hacker News
- Google API Keys Weren't Secrets. But then Gemini Changed the Rules. - Truffle Security
Google 官方文件
- API keys for Firebase services are not secret - Firebase Security Checklist
- Gemini API Billing - Google AI for Developers
- Troubleshooting: Google's security measures for leaked keys - Google AI for Developers
相關文章
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
