Firebaseのセキュリティルールはどこで設定する？

Firebaseのセキュリティルールはどこで設定する？

2020年10月31日

Firebaseのセキュリティルールはどこで設定する？

フロントエンド（Webブラウザ）からFirebaseのデータベースやストレージ機能を利用する場合、セキュリティルールをきちんと設定することがとても大切です。
ところで、どのセキュリティルールを実際に使っているかきちんと理解しておくことが大切です。

FirebaseのセキュリティルールはFirebaseコンソールで確認

現在、有効になっているFirebaseのセキュリティルールはFirebaseコンソールで確認できます。まずは、Firebaseコンソールで現在有効になっているセキュリティルールを確認するようにしてください。

Firebaseのプロジェクト作成時はFirebaseコンソールで決める

Firebaseのプロジェクトを作成して、最初にFirebaseのデータベースやFirebaseのストレージ機能を有効にする際には、セキュリティルールをそれぞれ設定する必要があります。このルールはFirebaseコンソールで行います。最初はテンプレートとなる標準の設定で設定する場合がほとんどで、他ではセキュリティルールの設定は行っていないので大きな問題はありません。

注意するのは「firebase init」を実行した後

Firebaseのプロジェクトをインターネットに公開（デプロイ）する際は、Firebaseのプロジェクトフォルダーを作って「firebase init」を実行する必要があります。この実行をした後は要注意です。「firebase init」の設定で、FirebaseのデータベースやFirebaseのストレージを使用する設定を選択した場合は、セキュリティルールのファイルがプロジェクトフォルダに作成されます。
firestore.rule
storeage.rule
です。初期設定時は、Firebaseコンソールで設定したルールがコピーされます。
この後に、開発で必要なルールをFirebaseコンソールで設定して動作確認をしながら開発を進める事はよくあることです。問題は、そのあとで作成したWebサービスやWebアプリをインターネット上に公開（デプロイ）する場合です。「firebase deploy」を実行すると、Firebaseのプロジェクトフォルダに保存されているルールを適用します。したがって、このルールがFirebaseコンソールのルールと異なる場合、Firebaseコンソールのルールを上書きしてしまいます。
この場合、実際にインターネット上で利用されるルールが書き換えられてしまう可能性があります。 Firebaseコンソールでルールの更新を行った場合、同時にFirebaseのプロジェクトフォルダのルールも更新しておかないと、古いルールを適用する場合があります。

同じプロジェクトで複数のアプリを作る場合も注意！

Firebaseのプロジェクトで複数の異なるアプリを作ることが可能ですが、この場合は特に注意が必要です。一つのFirebaseのプロジェクトに対して、データベースやストレージ（のバケット）は一つです。つまり、セキュリティルールも共通のものを使います。
別のアプリの場合、通常はFirebaseのプロジェクトフォルダも別に作成する場合がほとんどですので、セキュリティルールも複数の場所に存在することになります。
私も複数のプロジェクトを作る場合、意図しないルールでFirebaseコンソールのルールを上書きしてしまって、思ったような動作をしない経験をよくしています。

Firebaseのセキュリティルールを上書きした場合の対処方法

万が一、Firebaseのセキュリティルールを上書きしてしまった場合の対処の方法です。Firebase Cloud FirestoreとFirebaseストレージでは対処方法が違ってきます。

Firebase Cloud Firestore (データベース)の場合

FirebaseコンソールでFirebase Cloud Firestoreのセクションに行くとセキュリティルールを確認できます。よく見ると、ルール更新の履歴が残っています。この履歴をたどれば、以前のルールの記録が残っています。これを見つけて、Firebaseのプロジェクトフォルダのセキュリティルールを更新すれば解決です。
同時に、再度デプロイ（firebase deploy）を実行するか、Firebaseコンソール上でルールの更新を行えばセキュリティルールの上書きによる問題は解消されます。
したがってやるべきことは、どのデプロイでルールを上書きしてしまったのかを特定できればすぐに解決できます。

Firebaseストレージの場合

Firebaseストレージの場合は、Firebase Cloud Firestoreの場合と異なり、セキュリティルールの変更履歴が残されていません。したがって、以前に設定していたルールを復活させることはできません。再度、必要なセキュリティルールを書いて再設定をする必要があります。
シンプルなルールの場合は余り大きな問題でない場合が多いですが、複雑なルールやフォルダ毎に別々のルールを設定している場合復旧が大変な場合もあります。
したがって、Firebaseのストレージのセキュリティルールを更新する際は、同一プロジェクトでFirebaseのストレージのセキュリティルールを持っているすべてのFirebaseのプロジェクトフォルダのルールを更新する習慣をつけた方が無難です。

まとめ

Firebaseのセキュリティルールは基本的にFirebaseコンソールで設定・確認を行います。ただし、Firebaseのプロジェクトフォルダーが複数あるプロジェクトの場合、セキュリティルールがファイルとして各プロジェクトフォルダーにコピーされている場合があります。その場合、公開の処理（デプロイ）を行うと、FirebaseコンソールのセキュリティルールがFirebaseのプロジェクトフォルダに保存されているセキュリティルールで上書きされてしまいます。
これが原因で意図しないセキュリティルールが適用されて起きる不具合があります。
こうした不具合を避けるためにも、Firebaseのプロジェクトフォルダを作成後は、Firebaseコンソールのルールを更新した際は、各Firebaseプロジェクトフォルダに保存されているセキュリティルールのファイルを更新するようにすると問題を防ぐことができます。
ちょっとした事ですが、習慣にしておくと意図しないFirebaseのセキュリティルールの適用を最小限にすることができます。

コメント