FirebaseのAPIキーは公開しても大丈夫だよ（2020年夏）
毎年100回くらいこれ言ってると思うんだけど、いまだに「FirebaseのAPIキーを公開しても大丈夫かどうか不安」という人がいるし、 なんなら「FirebaseのAPIキーを公開してはいけません」とか大嘘をでかい声でしゃべる人もいます。
2020年の夏ももうそろそろ終わりますし、もう同じことを言うのも飽きたのでブログ記事に残すことにしました。
FirebaseのAPIキーは公開しても大丈夫です。
Disclaimer
この記事ではFirebaseのAPIキーに関する解説です。 GCPを含む他のサービスのAPIキーを同様に取り扱ってよいかどうかに関しては何ら言及していませんので、混同しないでください。
また、この記事は2020年8月30日くらいの情報をベースに書いています。 特に、Hosting上にデフォルトで公開されているinit.jsあたりの挙動は将来変更されるかもしれません。 最新の話は未来の僕を捕まえて聞いてみてください。 Firebase熱を失ってなければなんかしらの情報が得られるでしょう。
なんで大丈夫なの？
Hostingを使っている場合はおそらく全てのFirebaseプロジェクトにおいて、相対パスで /__/firebase/init.js あたりにてAPIキーが公開されています。
このブログもFirebaseでホストしていますので、ここで公開されています。
最近作成されたプロジェクトではコンソール上で上記の案内がなくなったようですが、CDN経由の読み込み方法としては下記のスクリーンショットのような説明があります。
ご覧の通り、APIキーを <body> タグ内に貼れという指示があります。
天下のGoogle様が公開したらマズいもんに関してこんな説明をすると思いますか？1
Webアプリでもネイティブアプリでも、APIキーを埋め込んだアプリケーションを配布しているわけです。 リバースエンジニアリングされたらキーは漏れます。
いずれにせよ、Firebaseを利用するエンジニアがいちいちAPIキーを隠す努力をするのは無駄です。 無駄なことに労力を割くのはもったいないのでやめましょう。
バージョン管理の話
Gitなどのバージョン管理システムにAPIキーを上げるなという意見もちらほら見ます。 GitHubに乗せるとGoogle様もたまに勘違いなされて警告メールを送ってきたりしますが、そもそもインターネッツの大海に公開されているものをGitでどうこうの議論をするほうがナンセンスだと思います。 僕は普段のプロジェクトではGitで管理しますが、面倒な手続きが好きな方は好きなようにすればいいと思います。
もうちょっと安全を確保したい人向けコンテンツ
Firebaseの各サービスはクライアントから直接アクセスを受けることを前提として設計されているため、認証情報をクライアントに持たせる必要があります。 mBaaS自身のAPIキーをサーバサイドに隠しても、結局そのサーバサイドにアクセスするために何らかの認証機能を作らなければいけなくなります。 これはWebアプリでもネイティブアプリでも同じです。
とはいえ、何も考えずにAPIキーを公開すると勝手にアプリを作られてAuthenticationのユーザを作られたり、 Firestoreに変なデータを作られたりして大変なことになるのも事実です。 ここでは、APIキーの利用を制限する方法を紹介しておきます。
APIキーの利用を制限する
GCPコンソール内にある APIとサービス > 認証情報 (https://console.developers.google.com/apis/credentials) にアクセスします。 Firebaseを使っている場合は、自動作成されたAPIキーが4つくらいあるはずです。
APIキーの名前のところがリンクになっているので、Webアプリの場合はBrowser Key、ネイティブアプリの場合はそれぞれのキーを選択して次の画面に進みます。 Webアプリの場合は、アプリケーションの制限 のところでHTTPリファラーを選択します。
すると、ウェブサイトの制限 という項目が表示されます。 新しいアイテムの入力フォームにWebアプリで利用しているドメインを追加します。
こうすることで指定したリファラーの範囲にAPIキーの利用を制限することができます。
リファラーにlocalhostを含めてしまうと、結局誰でもAPIキーが使えるようになってしまうので注意してください。 開発用途でlocalhostが使いたいかつ真面目に管理が必要な場合は、推測困難なポート番号を使うなり、開発環境と本番環境を分離するなり、IP制限を使うなり、 要求されるセキュリティレベルに応じて対策を講じましょう。
ここでは省略しますが、同様の手順でAndroidアプリの場合はパッケージ名とSHA-1署名証明書のフィンガープリント、iOSアプリの場合はバンドルIDによってAPIキーの利用を制限することができます。
セキュリティルールを設定する
上記の手順では、あくまでAPIキーを意図しないアプリケーションから利用されるリスクを軽減しているに過ぎません。 Firestore(Realtime DB含む)とStorageに関してアプリケーションの要件として妥当な操作に制限するためには、セキュリティルールを適切に記述します。
このへんは解説し始めるとそれだけで大長編になってしまうので、拙著を読んでいただければと思います（宣伝）。
- 僕は思いません。↩