長年にわたり、GoogleはAPIキーをウェブサイトのソースコードに直接埋め込んで、見えるところに安全に置くことができると、開発者を安心させてきました。「AIza」プレフィックスで容易に識別できるこれらの暗号化キーは、Google MapsやFirebaseなどのサービスを実現するために、ウェブページに日常的に統合されています。しかし、この長年の慣例はもはや安全でないことが最近明らかになりました。
Geminiの登場により、公開リポジトリにある同じキーが、公開を意図していない機密データへのアクセスを不注意にも解放する可能性があり、同時に大規模言語モデルへの不正なリクエストを通じてプロジェクト所有者の財務資源を枯渇させることができます。
The Digの調査ジャーナリストは、この脆弱性は根本的にアーキテクチャの問題だと主張しています。Google Cloudエコシステム内では、同じキー形式が2つの全く異なる機能に使用されます。歴史的には、このキーは秘密の暗号化シークレットではなく、主に請求と管理追跡のための「プロジェクト識別子」として機能してきました。その結果、Googleは明示的にAPIキーが機密情報を構成しないと述べており、Google Mapsのドキュメントはさらにキーをページのソースコードに直接埋め込むことを積極的に推奨していました。これらのキーはリクエストの起源に基づく制限（承認されたウェブアドレスの指定ホワイトリストなど）を持っていますが、キー自体は最初から堅牢で本格的な認証情報として機能するために設計されておらず、そのためこれらのセーフガードは頻繁に回避されます。
ドキュメントではGenerative Language APIと呼ばれるGemini APIが同じプロジェクト内で有効化されると、このダイナミクスは劇的に変わります。有効化されると、プロジェクト内の既存キーは非常に機密性の高いGeminiエンドポイントへのアクセスを突然継承する可能性があります。調査者らはインターフェース警告、メール通知、または追加の確認要求が著しく欠落していることを観察しました。もともと無害なマップウィジェット用に生成され、公開されているJavaScript内で何年も放置されていた従来のキーは、突然Geminiのマスターキーに変換されます。Geminiを内部プロトタイプで有効化するために必要なのはわずか1つのチームメンバーだけです。その間、古いキーは変更されず、ウェブサイトのソースアーキテクチャ内で休止状態でありながらも、依然として強力な状態で存在し続けます。
著者らは非常にシンプルで危険な攻撃ベクトルを説明しています。悪意のある行為者はページのソースコードから公開されているキーを抽出し、その後このクレデンシャルを使用してGeminiインターフェースにリクエストを送信します。絶対的なサービス拒否に遭遇する代わりに、サーバーは成功のレスポンスをもたらします。研究者によると、これらの不正なリクエストはアップロードされたファイルのレジストリと保存されたコンテキストデータを明かすことができます。さらに、彼らはモデル呼び出しの費用を人為的に膨らませたり、APIレート制限を枯渇させたりして、正当なアプリケーションを事実上麻痺させることができます。注意すべき重要なニュアンスがあります。被害者の基盤となるインフラストラクチャを侵害することは全く必要ではなく、公開リポジトリから公開されているキーをコピーするだけで十分です。
この脆弱性の真の規模を確認するために、調査者らは2025年11月のCommon Crawlデータセットを精査しました。彼らは2,863個のアクティブなGoogle APIキーの発見を宣言しました。これらはすべてパブリックドメイン内に放置されながら、同時にGeminiへの無制限のアクセスを所有しています。彼らは、影響を受けた企業は金融セクター内の巨大な企業、尊敬されるサイバーセキュリティ企業、国際的な人的リソース企業、そして逆説的にはGoogle自体を含むと主張しています。印象的な実例として、彼らはGeminiの発案自体より前の少なくとも2023年2月以来、公開されたGoogleプロダクトページのソースコード内に位置するキーを監査しました。/modelsエンドポイント経由の問い合わせは成功のレスポンスをもたらし、利用可能なモデルの包括的なマニフェストを提示しました。著者らは、このキーは厳密に平凡なパブリックプロジェクト識別子として利用されており、「生成的な」機能を呼び出すための任意の試みが全くないことを強調しています。
これらの重大な脆弱性は2025年11月21日にGoogleに公式に開示されました。最初に、企業は異常を「意図された行動」として却下しました。しかし、企業自身に属する侵害されたキーに直面させられると、ステータスは急ぎ本当の脆弱性として再分類され、エスカレートされた影響評価を伴いました。セキュリティチームはその後、監査中に発見された公開されたキーの包括的な台帳をリクエストし、許可されました。その後、著者らによって説明されたように、Googleはこれらの漏洩した認証情報を探し出すための内部イニシアチブを開始し、体系的にGeminiへのアクセスを削減しながら同時に根本原因の永続的な修復について検討しました。2026年1月13日までに、欠陥は公式に「シングルサービス権限昇格、READ」脆弱性としてティア1の深刻度で成文化されました。2026年2月2日時点で、調査者らは基盤となる欠陥を是正するための取り組みがまだ進行中であることに気づきました。2026年2月19日に標準的な90日開示ウィンドウが終了に向かうのと同時に。
GoogleはAI Studio内で新たに生成されたキーをデフォルトでGeminiに制限することを積極的に述べており、不注意なクロスサービス操作の可能性を中立化しています。さらに、企業は不正なGemini呼び出しを示すデータリーク内で傍受されたキーを先制的にブラックリストに登録する計画を立てており、これらの侵害された認証情報に関する事前通知をプロジェクト所有者に配信することを約束しています。
Google Cloudエコシステム内にいるエンジニアリングチームにとって、教訓は厳然として実用的です。プロジェクト内でGeminiが有効化された場合、すべてのAPIキーを監査し、Gemini特権を持つ認証情報が公開されたウェブサイトやオープンソースリポジトリに不注意のうちに漏れていないことを確保することは絶対に不可欠です。歴史的にマップと多様な「クライアント側」アプリケーション用に生成された従来のキーは、時代遅れのセキュリティパラダイムの厳密な遵守で数年間体系的に公開されているため、特に危険な脅威を与えます。キーがGemini互換性を保持しながら著しく公開されていることが判明した場合、それを無効化して置き換えることが最重要です。その後、管理者は公開インターフェース用に運命づけられたキーがGeminiの機密データリザーブのロックを解除できないままであることを明確に保証し、サービスとチャネル制限を慎重に設定する必要があります。
