Google API key 變高危：用過 Maps、Firebase、Gemini 要即刻查清楚

圖：TechCrunch．原文連結

TechCrunch 這篇訪問的表面主角是 Google Cloud 高層談 AI 安全，但真正值得停低看的，不是又一次叫企業要有安全策略，而是 Google 自己也被捲入同一個過渡期。過去很多開發者把 Google API key 當成公開識別碼：Maps 放在前端、Firebase config 放在 app、demo key 留在舊 repo，最多只是怕被人偷用地圖額度。到 Gemini API 介入後，這個假設變得不夠安全，因為同一類 AIza... key 可能不再只是識別項目，而是會觸及收費 AI 服務、上載檔案同快取內容。

事件的核心不是單一漏洞，而是一組設計選擇碰撞。Google Cloud COO Francis de Souza 在 TechCrunch 訪問中提到，AI 安全不能事後補上，企業要把資料策略、安全策略同 AI 策略一齊處理；這個方向沒有錯。問題是，平台供應商自己同樣在邊行邊改：舊 Google Maps、Firebase、Google Cloud API key 的使用習慣，是在 AI 服務大規模商用之前形成；當 Gemini 變成同一個 Cloud project 入面的可啟用服務，舊 key 的風險面就被拉大。

舊 key 點樣變成新風險

Truffle Security 在 2026 年 2 月公開的研究指出，Google Cloud 長期使用同一種 API key 格式去處理兩類很不同的事情：一邊是公開可見、用來識別項目同計費的 key；另一邊是可以呼叫敏感服務的憑證。研究人員掃描公開網頁資料後，找到接近 3,000 條仍然有效、並可用於 Gemini 相關端點的 Google API key，當中不少原本是為 Maps、Firebase 等公開前端場景而存在。Truffle Security 是安全公司，本身有產品利益，所以不能把它當成唯一結論；但它提出的攻擊路徑，已被 The Register 後續用戶個案同 Google 官方文件變動交叉印證。

Google 官方文件其實也反映到安全口徑正在收緊。Firebase 安全清單仍然說，Firebase 服務用的 API key 在符合指引、受 Firebase 相關 API 限制時，不需要當成秘密；但同一頁已提醒，如果 app 用其他 Google 服務，例如 Places API 或 Gemini Developer API，就應該用另一條獨立 key 並限制到相應 API。Gemini API 文件則講得更直接：Gemini API key 要像密碼一樣保護，不應提交到 Git，也不應在正式環境直接放在網頁或手機 app 前端。這不是普通文案更新，而是代表舊時「key 可公開」的直覺，已經要按服務重新判斷。

The Register 在 5 月報道多宗用戶被盜用 Google API key 後產生高額帳單的個案。最典型的是原本只用 Google Maps 的開發者，突然因 Gemini、Veo 或圖像生成相關用量被收取數千至五位數美元帳單；有受訪者表示自己以為設了較低支出上限，但 Google 的自動用量級別機制在符合條件後可把可用額度推高。Google 後來向 The Register 兩名具名受訪者退款，但同時表明仍會保留自動提升用量級別的政策，理由是避免正常服務因人為上限而中斷。對小團隊來講，這正正是最難受的位置：平台想保障可用性，但被盜用時，這個設計會放大損失。

刪 key 不等於即時止血

Aikido 在 5 月 21 日公開的測試令事件再升級。研究指刪除 Google API key 之後，撤銷狀態不是即時同步到所有基建；10 次測試中，最長仍可成功驗證接近 23 分鐘，中位數約 16 分鐘，最短也接近 8 分鐘。更麻煩的是，成功率不是線性下降，有些分鐘大部分 request 仍然通過，有些分鐘又幾乎全部失敗。Aikido 初時表示 Google 將報告關閉為 won’t fix，但在 5 月 22 日更新稱 Google 已重開報告並把它當成 P0 bug 處理；這個更新很重要，因為代表狀態仍在變動。

這 23 分鐘不是抽象的工程延遲。假如 key 已外洩，而同一個 project 啟用了 Gemini，攻擊者可以在你按下刪除之後繼續狂打 API，嘗試打中未完成同步的伺服器；如果 project 內有 Gemini Files API 上載檔案或 cached content，風險就不只是一張帳單，還包括資料被讀走。Aikido 建議把刪除 Google API key 視為一個 30 分鐘的事故處理窗口，在這段時間內到 Cloud Console 的 Enabled APIs and services 檢查按 credential 分拆的 request，用實際流量確認有沒有仍在被濫用。

開發團隊現在要查的幾件事

這次最應該避免的反應，是只叫人「不要把 key 放上 GitHub」。當然，密鑰不應入 repo，但 Google Maps JavaScript API 官方教學本身就要求每個前端 request 帶 API key；問題在於 key 應該被限制到正確 app、正確來源同正確 API，而不是一條 key 行晒所有服務。Google Cloud 的 API key 文件也寫明，不受限制的 key 可以被任何人、從任何地方使用；正式環境應同時設 application restrictions 同 API restrictions。

實務上，最少要做以下檢查：

• 在每個 Google Cloud project 入面，去 APIs & Services 查是否啟用了 Generative Language API 或 Gemini 相關服務。
• 去 Credentials 檢查所有 API key，特別是標示 unrestricted、沒有 API restrictions、或明確容許 Generative Language API 的 key。
• 搜尋前端 bundle、舊網站、WordPress 外掛設定、mobile app config、公用 Git repo、CI log、文件截圖，睇有沒有同一條 key 出現。
• Maps 前端 key 應限制到 Maps JavaScript API 或實際用到的 Maps API，並加 HTTP referrer；server-side key 應用 IP restriction。
• Gemini 用 key 應放 server-side，獨立 project 或至少獨立 key；不要同 Maps、Firebase、CMS 外掛、demo project 共用。
• 如發現外洩，先停用相關 API 或加限制，再輪換 key；刪 key 後預留 30 分鐘監察有效驗證同帳單走勢。
• 設 budget alerts、服務層 quota 同用量監察，但不要把 budget alert 當成即時硬上限或防火牆。

香港情況要講清楚

到目前公開報道為止，未見 TechCrunch、The Register、Aikido 或 Truffle Security 點名香港受害個案，所以不應把事件寫成本地爆煲新聞。不過香港團隊的實際風險很直接：本地 startup、網店、預約系統、地產平台、物流小工具、agency 代客網站、SaaS 後台、校內 IT side project，都很常見把 Google Maps 或 Firebase 快速接入產品。這些部署未必有專職保安人員長期審 Cloud Console；一旦舊 key 被爬走，損失可能用美元計，追退款又要跨時區同支援流程拉扯。

Gemini 可用性方面亦要小心講。Google AI for Developers 的「Google AI Studio and Gemini API available regions」官方列表，截至 2026 年 4 月 28 日更新，未列出 Hong Kong；頁面建議不在列表地區的用戶可嘗試 Google Cloud 路徑。另一方面，Google Cloud 的 Gemini Enterprise Agent Platform / Vertex AI 相關地區文件列出 Hong Kong (asia-east2) 作為 Google model endpoint location 之一。因此香港帳戶不是一句「全部都可直接用 AI Studio」就講完：直接 AI Studio / Gemini API 路徑同 Google Cloud 企業路徑要分開核實，實際可用性亦受帳戶、組織政策、地區、付款同服務條款影響。

這不是只屬於 Google 的問題

AI 服務把計算成本、資料存取同自動化代理放到同一個平台，令舊憑證設計更容易出事。以前一條 key 被偷，可能只是被人盜打地圖或翻譯 API；現在同一個 project 啟用 AI 服務後，攻擊者可以用更昂貴的模型、耗盡 quota，甚至嘗試讀取 AI workflow 留低的檔案同快取內容。TechCrunch 原文提到 shadow AI、舊 SharePoint、代理自動在公司系統穿梭，重點其實一樣：AI 不是在原有 IT 架構旁邊加一層魔法，而是會把舊權限、舊資料、舊 key 全部重新暴露出來。

Google 的官方補救方向包括阻擋長期休眠而不受限制的 key、要求 Gemini API traffic key 在 2026 年 6 月 19 日前加限制，以及在 AI Studio 顯示不受限制 key 的提示。這些都比以前好，但對已經有多年歷史的 Cloud project 來講，真正工作仍在用戶自己手上：逐個 project 查、逐條 key 分類、把公開識別碼同敏感憑證拆開、把 AI 原型同正式 Maps/Firebase 服務隔離。最保守的結論是：任何曾經出現在前端、repo、文件或外判交付包的 Google API key，都不應再被假設為低風險。

參考來源

• TechCrunch — Everyone is navigating AI security in real time — even Google — original report
• Google API Keys Weren't Secrets. But then Gemini Changed the Rules. — 第三方安全研究，提出舊 Google API key 在 Gemini 啟用後可能變成敏感憑證的技術路徑同規模資料。
• Google users fight for refunds as unauthorized API usage bills soar — 用戶個案同 Google 回應來源，交叉核實高額帳單、Maps key、Gemini / Veo 用量同自動提升用量級別爭議。
• Google API keys keep working after you delete them — Aikido 原始測試，提供刪除 Google API key 後最多接近 23 分鐘仍可驗證，以及 30 分鐘事故處理建議。
• Using Gemini API keys — Google 官方 Gemini API key 文件，核實 key 應保密、避免前端暴露、限制 key，以及 2026 年 6 月 19 日後不再支援不受限制 traffic key。
• Available regions for Google AI Studio and Gemini API — Google 官方地區列表，用來核實 Google AI Studio / Gemini API 直接路徑未列出 Hong Kong，並提示可考慮 Google Cloud 路徑。
• Deployments and endpoints — Gemini Enterprise Agent Platform — Google Cloud 官方地區文件，核實 Hong Kong (asia-east2) 在 Google Cloud 相關 Gemini model endpoint location 列表中。
• Learn about using and managing API keys for Firebase — Firebase 官方文件，核實 Firebase key 的限制策略，以及不要把 Gemini Developer API 放入公開可存取 key allowlist 的建議。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。