【こわい】Google APIキーの脆弱性により13時間で約900万円請求される事案が発生！ Firebase×Geminiで今すぐやるべきセキュリティ対策

279

Posted at 2026-04-17

はじめに

こんばんは、mirukyです。
この画像を見てください。

この画像の通り、「FirebaseサービスのAPIキーは非公開ではない」と、Firebaseの公式ドキュメントには書かれています。説明の必要は無いかもしれませんが、FirebaseとはGoogleが提供するモバイル・Webアプリケーション開発プラットフォームです。この通り、フロントエンドのHTMLにAPIキーを埋め込むのは、Googleが推奨してきた設計方針でした。

ところが先日、Firebase AI Logicを有効化したプロジェクトで、 たった13時間で€54,000（約900万円） のGemini API請求が発生する事案が起きました。
この事案は結構「明日は我が身」案件だと思ったので、記事として共有できればと思います。

原因はかなりシンプルです。GCPでAPIキーを作成すると、デフォルトで すべてのAPIにアクセスできる「制限なし」状態 になります。Gemini APIが有効化された瞬間、公開状態だったFirebaseのAPIキーがGeminiの認証情報としても機能するようになり、攻撃者に悪用されました。

この記事では、事件の背景と今すぐやるべき対策をまとめます。以前、AWSでのDDoS（EDoS）によるコスト爆発について書きましたが、クラウドの請求爆発はプラットフォームを問わず起こりうる問題です。

1. 何が起きたのか

被害者は1年以上前にFirebase認証用に作成したプロジェクトを有しており、最近になってシンプルなAI機能（テキストプロンプトからWebスニペットを生成する機能）を追加するためFirebase AI Logicを有効化しました。その直後から深夜にかけて大量の不正リクエストが押し寄せ、€54,000超の請求が発生した、というものです。

項目	内容
被害額	€54,000以上（約900万円）
発生時間	約13時間（深夜帯）
予算アラート	€80に設定済み → 数時間遅れで発火（到達時点で€28,000）
Googleの回答	「正当な使用」として請求調整を拒否

同様の被害は他にも報告されており、13,428USD、82,000USDといった請求がそれぞれ別のユーザーから寄せられています（調べると結構出てきます）。

下の方のredditでは、このままでは倒産してしまう、というかなり悲痛な声があります。82000USDは約1200万円なので、当然でしょう、、。普通にサイバー犯罪の被害者なので、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（遡及的な権限拡大）」 と呼んでいます。
こんな感じのイメージですね。これは一例です。

攻撃は驚くほど単純で、Webサイトのページソースから AIza... キーをコピーして以下を叩くだけです。

curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"

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で月250USD、Tier 2で月2,000USDなど）。プロジェクトレベルの上限も AI Studioの費用ページから設定可能です（ベータ版）。

ただし 最大10分の処理遅延 があるため、高速な攻撃を完全には防げません。GCPの Quotas（割り当て） はリアルタイムで適用されるため、「IAMと管理」>「割り当て」からGenerative Language APIのリクエスト数を制限しておくと効果的です。

【プリペイド方式】

2026年3月23日から導入されたプリペイド方式では、事前に$10〜$5,000のクレジットを購入し、残高ゼロで即座にサービス停止になります。新規ユーザーはデフォルトでプリペイドに割り当てられます。

プリペイドのオートチャージを有効にする場合は、チャージ額を低く設定してください。攻撃時に自動補充され続けるリスクがあります。

3-4. APIキーを用途ごとに分離する

1つのキーを複数の用途に使い回さず、用途ごとに分離します。

Firebase用キー Firebase Authentication・Firestoreなどに限定
Maps用キー Maps JavaScript APIに限定、HTTPリファラー制限を設定
Gemini API用キー Generative Language APIに限定、 サーバーサイドでのみ使用

Gemini APIキーをクライアントサイドのJavaScriptに含めるのは避けてください。フロントエンドで呼び出す必要がある場合は、Firebase App Checkの導入を検討してください。

4. Googleの対応と残る課題

4-1. これまでの経緯

Google翻訳で翻訳しているので、変な日本語訳箇所があるかもです。

Truffle Securityは2025年11月にこの脆弱性を報告しましたが、Googleは当初「意図された動作」として却下しました。Google自身のインフラに影響がある具体例を提示した後、ようやく「バグ」に再分類されています。2026年1月に「Single-Service Privilege Escalation, READ」（Tier 1）として認定され、2月25日にTruffle Securityがブログで、上記の詳細を公開しました。

Googleが現在進めている主な対策は3つあります。

Auth Keys（認証キー）の導入 AIza... とは異なる安全なキー形式を新規ユーザーに提供
漏洩キーの自動ブロック 公開が確認されたキーのGemini APIアクセスを自動遮断
制限なしキーの無効化を予定 Geminiプロダクトリードが「制限なしキーでのGemini API使用を無効化する方向で進めている」と言及

4-2. まだ残る課題

既存の制限なしキーが自動的に安全になるわけではありません 。API制限の設定は、プロジェクトオーナーが自分で行う必要があります。予算アラートの遅延問題も未解決で、クラウドの請求システムに完全なハードキャップは依然として存在しません。

おわりに

ここまでお読みいただきありがとうございます。

GCPのAPIキーが「デフォルトで制限なし」に設定される仕様と、Gemini APIの登場で AIza... キーが認証情報として機能するようになった変化。この2つが重なり、公開状態のキーから数時間で約900万円の請求が発生する事態になりました。

最も重要な対策は、今すぐGCPコンソールを開いてAPIキーの制限設定を確認することです。キーの定期ローテーション、利用額上限やプリペイドの設定もあわせて実施してください。

ではまた、お会いしましょう。

参考リンク

事件・脆弱性報告

Google公式ドキュメント

DDoS攻撃でAWS請求が200万円に！S3・CloudFrontで絶対やるべきコスト爆発防止策 6選 - Qiita

279

213

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up