個人開発プロジェクトのセキュリティ編、Part 2です。
前回はFirestoreのセキュリティルールを設定して「データベースの中身」を守りましたが、
今回は「APIキーそのもの」の守りを固めていきます。
Firebaseを使っていると
「APIキーがフロントエンド（ブラウザ）で見えてしまうけど大丈夫？」と不安になったことはありませんか？
結論から言うと、APIキーを完全に隠すことはできません。
だからこそ、「万が一キーが見られても、あなたのサイト以外では絶対に使わせない」という設定（Restrictions）が不可欠です。
今回はGCPコンソールを使って、鉄壁の制限をかける手順を解説します。これをやれば、枕を高くして眠れるようになりますよ。
前回のおさらい：セクション５(セキュリティロードマップ）
アプリのセキュリティの向上ロードマップ
Part1：Firestore DB セキュリティルールの内容変更。- Part2：API Key Restrictions。GCPでのHTTPリファラーとAPI制限を設ける。（今回）
- Part3：環境変数の整理 (.env)。プロジェクト内APIの整理。
- Part4：予算アラートの設定。GCPで行う、もしもの備え。
.env と Restrictions の決定的な違い
「APIキーは .env ファイルに入れて隠せば安全じゃないの？」
そう思う方も多いかもしれません。確かにサーバーサイド（バックエンド）の開発ではそれで正解です。
しかし、Firebaseのようなフロントエンド（ブラウザ）で動くアプリの場合、仕組み上どうしてもAPIキーがネットワーク通信の中に露出してしまいます。
つまり、知識がある人が見ればキーは見えてしまうのです。
そこで登場するのが Restrictions（制限） です。
この2つの違いを、クレジットカードに例えると分かりやすいでしょう。
- .env (隠す):
-
クレジットカード番号をSNSに晒さないこと。
- Restrictions (制限する):
-
カード会社に電話して「日本国内でしか使えないように設定してください」と頼むこと。
たとえカード番号（APIキー）が誰かに知られてしまっても、「あなたの指定した場所（サイト）以外では使えない」という状態にしておけば、悪用されるリスクは限りなくゼロに近づきます。
これが今回の狙いです。
| 項目 | .env / .gitignore | API Key Restrictions (今回やること) |
| 役割 | 「隠す」 (Hiding) | 「範囲を限定する」 (Limiting) |
| 守る場所 | GitHub (ソースコード) | Google Cloud Platform (サーバー側) |
| イメージ | クレジットカード番号をSNSに投稿しないこと。 | 利用可能エリアを限定する |
今回やること：GCPでかける「2つの鍵」
では、具体的にGCP(Google Cloud Console） のコンソールで何を設定するのか？
やることは大きく分けて2つだけです。
「どこから使えるか？」を制限します。
「このURLは、開発中(http://localhost:3000）と 本番(https://my-app.com）からのリクエストしか受け付けないで！」と門番にお願いするイメージです。
これにより、泥棒がキーを盗んで自分のサイトで使おうとしてもエラーになります。
「何を使えるか？」を制限します。
「このAPIキーは、データベース(Firestore) と 認証(Auth) しか使えないよ！ 高額な 地図(Google Maps) や カメラ(Vision API) は使わせないで！」と設定します。
これをしないと、もしキーが漏れた場合、勝手に高額なAPIを使われて請求が来るリスクがあります。
私が行った実装手順：GCPで鉄壁の制限をかける
それでは、Google Cloud Console（GCP）にアクセスして設定を行いましょう。
「Google Cloud Console」で検索するか、
Firebaseコンソールの [プロジェクトの設定] > [全般] > [Web API キー] のリンクからも飛べます。
※リンクは、GCPとFirebaseのトップページに移動します。
左メニューの「認証情報」をクリックし、「API キー」の一覧から、
現在Firebaseで使用しているキー（通常は Browser key ）をクリックして編集画面に入ります。
まずは「このアプリをどこから使えるか(URL)」を制限します。
- 「アプリケーションの制限」セクションで [HTTP リファラー (Web サイト)] を選択。
- 「Web サイトの制限」という項目が出るので、以下のURLを追加します。
- ローカル開発環境:
http://localhost:3000
※ ポート番号（:3000など）まで正確に入力してください。 - 本番環境:
https://your-app-domain.com
※ 自身のデプロイ先URLです。 - プレビュー環境:
https://your-project-id.web.app
※ プレビューURLなど、必要に応じて。
- ローカル開発環境:
「開発中の画面」自体は不要？
結論から言うと、開発中(https://studio.firebase.google.com/) そのものは不要です。
なぜなら、Firebaseへのリクエスト（データの読み書きなど）を行っているのは、Studioのエディタ画面ではなく、そこで動いている 「あなたのアプリ（プレビュー）」 だからです。
次に「このキーで何を使えるか」を制限します。これ重要です。
- 「API の制限」セクションで [キーを制限] を選択。
- プルダウンメニューから、このアプリで「本当に必要なAPIだけ」にチェックを入れます。
※わからない場合は、必要そうなのでOKです。後でエラーを確認します。
- Cloud Firestore API
- Cloud Datastore API
- Firebase App Hosting API
- Firebase Installations API
- Firebase Remote Config API
- Firebase Remote Config Realtime API
- Identity Toolkit API (これがFirebase Authのことです)
もし将来、Google Maps機能などを追加したくなったら、その都度ここに戻って許可すればOKです。
設定が終わったら、画面下の [保存] を忘れずにクリックしましょう。
※反映には最大5分ほどかかる場合があります。
これで設定は完了し開発中のアプリをリロードしたところスッと更新されることになりました。
しかし問題は、本当にセキュリティが機能しているのか？という所です。
次は、HTTPリファラーを１つ削除して機能しているのか確認を行っていきます。
動作確認：あえて「エラー」を出して安心する/セキュリティチェック。
設定完了！…と言われても、本当に機能しているか不安になりませんか？
そこで、あえて設定を「崩して」、正しくブロックされるか実験してみましょう。
ここでは、「エラーが出れば大成功」です。
実験1：HTTPリファラーのブロック確認
まず、先ほど設定した「アプリケーションの制限」から、現在開発中の (PreviewURL) をあえて削除して保存してみます。
この状態で、ローカルのアプリをリロードすると…？
アプリの画面は真っ白、もしくは読み込み中のまま。コンソールには容赦ないエラーログ。
このキーが他人のサイトで使われても、この状態になるわけです。
実験2：API制限のブロック確認
次に、許可していないAPIが勝手に使われないかの確認です。
私の環境では意図せず Analytics API がリクエストを送っていたようで、Dev Console(F12)を確認するとしっかりブロックされていました。
APIキーで許可しているもの以外はブロックされている。(block:Analytics API)
もし制限をかけていなければ、知らぬ間に不要なAPIが動いて通信量が増えていたかもしれません。
「許可したもの以外は通さない」。この鉄壁の守りが機能している証拠です。
これで、万が一キーが漏洩しても
「指定したサイト以外では使えない」
「指定した機能以外は動かない」状態になりました。
※キャッシュの注意: APIキーの設定変更（特にリファラー）は、反映されるまで数分〜10分程度かかることがあります。「削除したのにまだ動く？」という場合は、少し待つかシークレットウィンドウで試すと確実です。
まとめ：もう「キーの漏洩」は怖くない
お疲れ様でした！ これで、APIキーには強固な鍵がかかりました。
Firebaseのようなフロントエンドで動くアプリは、どうしてもキーが露出してしまいます。
しかし、今回の設定で「見られても使えない」状態を作ることができました。
これこそが、個人開発を守る最後の砦です。
- GCPコンソールにアクセス
- APIキーの設定画面へ移動
- アプリケーションの制限 (HTTPリファラー)
開発環境ドメインと本番ドメインのみを許可- 自分のアプリ以外からのアクセスを遮断
- APIの制限
- 例(
FirestoreやAuth) など必要な機能だけを許可 - 高額なAPI（Maps等）の不正利用を防止
- 例(
- 動作確認（重要！）
- あえて設定を外してエラーが出ることを確認
- 守られていることを自分の目で実証
次回予告：Part 3 環境変数の整理 ＆ Part 4予算アラートの設定
セキュリティの不安がなくなったところで、
次回はPart 3とPart 4の内容を合併して、一気に開発環境の整備を完了させます！
「とりあえず動けばいいや」で散らかってしまったコード（環境変数）を整理し、万が一の「課金事故」を防ぐアラート設定まで。
環境変数の整理 (.env)
- 散らかったAPI呼び出しをスッキリ管理する
予算アラートの設定 (GCP)
- 「もしも」の高額請求を防ぐ通知設定
プロジェクトの総仕上げ
- 開発体験（DX）を向上させて、機能実装に集中する準備
最後まで読んでいただき、ありがとうございます。
もし「GCPの設定、放置してたかも…」という方は、ぜひ今すぐコンソールを確認してみてください。
その5分が、将来の数万円（請求）を守るかもしれません。
この記事が参考になったら、ぜひシェアやブクマをお願いします！
Tomoya
コメント