Hacker News
Google's Gemini API inadvertently turned previously public API keys used for services like Maps into sensitive credentials, leading to widespread privilege escalation risks and potential data exposure.
AI 生成摘要
Google 的 Gemini API 無意中將原本用於 Maps 等服務的公開 API 金鑰轉變為敏感憑證，導致廣泛的權限提升風險以及潛在的數據外洩。
Truffle Security 近期揭露了 Google API 金鑰（API Keys）存在的重大安全隱患。過去十多年來，Google 一直向開發者宣稱用於 Maps 或 Firebase 的 API 金鑰並非機密資訊，可直接嵌入前端程式碼中；然而隨著 Gemini AI 服務的推出，Google 預設將這些既有的「公開金鑰」權限自動擴展至具備敏感性質的 Gemini 介面，導致原本無害的網頁代碼瞬間變成了能存取私有數據並產生高額帳單的後門。
Hacker News 的討論聚焦於 Google 在產品設計上的結構性失誤，以及這類安全漏洞背後的產業趨勢。多數留言者認為這是一個極其諷刺的局面，並非單一開發者的疏失，而是 Google 為了急於推廣 Gemini 服務，忽視了權限隔離的基本原則。社群指出，核心問題在於 Google 允許使用「公開金鑰」來存取「私有數據」，這種權限設計邏輯本身就存在缺陷。
部分開發者對 Google 的處理方式感到憤慨，認為這反映了 Google 在競爭壓力下急於求成的魯莽。留言提到，許多金鑰是在多年前為了 Firebase 或 Firestore 等服務建立的，當時這些金鑰的功能受限且相對安全，但 Google 在推出 Gemini 時，卻未將其設為預設關閉，反而讓舊有的金鑰自動獲得存取新服務的權限。這種「隱性權限提升」讓原本遵循官方文件指引的開發者，在不知情的情況下暴露了公司的資產與預算。
此外，社群中也出現了關於文章風格的有趣辯論。有讀者質疑這篇由 Truffle Security 發布的技術部落格帶有強烈的 AI 生成痕跡，認為其結構過於工整、語氣過於一致，甚至開玩笑說這是一場「ChatGPT 攻擊 Gemini 安全缺陷」的數位戰爭。儘管如此，討論者普遍同意文章所指出的技術風險是真實存在的。
也有觀點認為這並非全新的問題，Google API 金鑰的混亂狀態由來已久，開發者長期以來一直對哪些金鑰需要保密、哪些可以公開感到困惑。社群共識傾向於認為 Google 應該採取更激進的補救措施，例如強制要求 Gemini 服務必須使用獨立的憑證，而非沿用舊有的 API 金鑰體系。目前 Google 採取的「封鎖已洩漏金鑰」做法被批評為治標不治本，因為在 Google 改變定義之前，這些金鑰在開發者眼中根本不屬於「洩漏」。
在討論過程中，開發者特別提到了 Google Cloud Platform (GCP) 的 API 限制功能，建議用戶應主動檢查並手動限制金鑰的使用範圍（API Restrictions），以防止未授權的服務調用。此外，TruffleHog 工具也被提及作為檢測現有金鑰是否具備 Gemini 存取權限的實用手段。