上個禮拜發表出來的災難,Google 的 Gemini 服務上把 API key 當作 credential 用:「Google API Keys Weren't Secrets. But then Gemini Changed the Rules. (via)」。
首先 API key 一直都被視為一般性的 identifier,不是 secret,這個也是目前常見的 pattern,需要帶權限操作時會再加上 secret key 才能存取。這點在 Google 很多文件都可以看到:

問題在於 API key 生成的設計中,預設開了所有的權限:

再加上 Gemini 只需要 API key 就可以對 Gemini 的 endpoint 存取資料,也就是文章裡面提到的,如果 endpoint 傳回 200 就代表大事不妙了,可以直接用 Gemini 的功能用到爽:
curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"
然後文章去撈了 Common Crawl 裡面的資料,發現有 2863 個 key 可以開心玩:
To understand the scale of this issue, we scanned the November 2025 Common Crawl dataset, a massive (~700 TiB) archive of publicly scraped webpages containing HTML, JavaScript, and CSS from across the internet. We identified 2,863 live Google API keys vulnerable to this privilege-escalation vector.
更開心的是他們發現 Google 自家的 API key 也有這個問題:
Proof of Concept: Google's Own Keys
We provided Google with concrete examples from their own infrastructure to demonstrate the issue. One of the keys we tested was embedded in the page source of a Google product's public-facing website. By checking the Internet Archive, we confirmed this key had been publicly deployed since at least February 2023, well before the Gemini API existed. There was no client-side logic on the page attempting to access any Gen AI endpoints. It was used solely as a public project identifier, which is standard for Google services.
當初這 design 怎麼過的 XDDD


