Firebaseの匿名認証はなんのためにあるのか - セキュリティ編

FirebaseのAuthenticationはGoogleログインやTwitterログインが簡単にできる便利なものですが、その中には匿名認証というものもあります。これが一体何のためにあるのか、セキュリティの観点から見てみます。今回はブラウザ上で動くWebアプリケーションの話です。

そもそも匿名認証とは？

匿名認証というのは、ユーザーが何も操作などをしなくても、内部で勝手にログインする機能です。

何のためにあるのか？

基本的には公式の説明にいきなり書かれています。

JavaScript を使用して Firebase 匿名認証を行う  |  Firebase

アプリに登録していないユーザーが、セキュリティ ルールで保護されているデータを使用できるようになります。

セキュリティとは？

Firebaseは便利ですが、怖いところがあります。Webアプリケーションの場合、JavaScriptを使うためFirebaseアプリケーションを初期化するための設定情報が丸見えになってしまいます。そのため、何のセキュリティも導入していないとその設定情報を使って誰でも勝手にそのアプリケーションの情報を読み書きできてしまいます。

それを制限する方法として、ForestoreやStorageにはセキュリティルールがあります。例えば以下のようなことが設定できます。

• あるデータは誰でも閲覧できる
• あるデータはログインしたユーザーしか書き込みできない

等。

セキュリティルールを設定しないとどうなるのか？

前述の通り設定情報が丸見えですので、それをコピーして誰かが自分のプログラムに組み込めば、他人のFirebaseのアカウントで自由にデータなどを扱えるようになってしまいます。

見られてはいけないデータが見られてしまいますし、そもそも利用量によって金額も増えてしまう恐れがありとても危険です。

匿名認証を使ったセキュリティ設定の一例

セキュリティ上問題ないと思われる、匿名認証を使ったシンプルな例をあげてみます。（一部誤りと追記修正を含んでいます）

全てのデータの読み書きを認証済みの場合のみ許可する

認証していない場合はあらゆるデータの読み書きを不可能にします。

匿名認証で誰もが必ず認証している状態にする

これで、ログイン機能がなかったり、手動でログインしたりしなくても全てのユーザーが読み書きできるようになります。

ログイン可能なホスト名を本番環境のみにする

Firebase ConsoleのAuthenticationの設定でログインできるホスト名を設定することができます。ここで本番のホスト名だけを認証可能にします。こうすることで、Firebaseの設定情報を使われてもデータにアクセスすることなどは不可能となります。

localhost等も当然消しておきましょう。開発時には別途開発用のFirebaseアプリケーションを用意し、そちらの設定を使ってください。ビルド時にはcross-envを使うと良いと思います。（誤りがあるので追記をご覧ください）

追記）
このホスト設定はリダイレクト用のため、匿名認証には利用できないようです。今のところ簡単に制限する方法はなさそうです。適切なセキュリティルールを設定してください。ルールの制限がないデータは今のところ他者に自由遊ばれる事ができてしまうのかもしれません…。良い情報があればぜひ提供をお願いします。

APIキーを制限する

Firebaseのコンソールでなく、GCPコンソールの方で制限が必要そうです。詳しくは下記に書きました。

GoogleからAPIキーが公開されているよとアラートが来た

まとめ

このように、匿名認証を入れることで本番でしかデータを扱うことができなくなり、セキュリティのベース部分の強化を行うことができます。（追記：前述の理由から、リダイレクトがないので本番以外でも扱うことはできるため、正しいセキュリティルール設定が必要です）

とにかく、設定情報が丸見えというのは非常に恐ろしい話です。当記事の話も鵜呑みにせず、しっかりと色々なパターンを考えセキュリティを強化しておきましょう。（むしろ間違っている話があればご指摘をお願いします）

Firebaseと連携するあらゆる処理をfunctionsに実装して設定情報は公開しないようにする、くらいの強固さで考えるくらいでも良いかもしれません。（認証の連携ができないので厳しいかもしれませんが）