Firestore セキュリティルール ～ テストのすすめ ～
2021.12.20
Firestore セキュリティルールをテストしよう
「Firestore（ファイアストア）」は、クライアントコードから、直接読み書きができるなどの機能を備えた、便利な NoSQL データベースです。
ですが、アクセス制限の要となるセキュリティルールの設定を怠ると、悪意あるユーザによって「データの改変・削除」がされる可能性があります。
本記事では、危険なセキュリティルールの例と共に、セキュリティルールをテストすることのメリットを紹介していきます。
セキュリティルールの手抜きは危険！？
Firestore では、クライアントコードから直接、データの取得・更新をリクエストできます。
Firestore を利用する上での大きなメリットの１つですが、その反面、クライアントコードに Firestore への接続情報を記述する必要があります。
セキュリティルールの設定が必要！
例えば、ウェブクライアントから Firestore を使用する場合、ユーザはクライアントコードから簡単に接続情報を確認できます。
そのため、Firestore 側で適切なアクセス制限（=セキュリティルール）が設定がされていないと、ユーザが自由にデータを取得・更新できてしまいます。
つまり、ユーザが悪意のあるユーザであった場合、データを悪用または破壊される可能性があります。
危険なセキュリティルールの例
危険なセキュリティルールの例を、いくつか挙げていきたいと思います。
【※注意※】
それぞれの例について、危険なセキュリティルールとより好ましいセキュリティルールを例示していますが、より好ましいセキュリティルールについても完全なものではありません。
解説のために簡略化したものとなりますので、実際に本番環境で使用する場合は、各環境に応じてルールを追加するなどの調整が必要となります。
なお、セキュリティルールの構成や設定の方法については、以下で解説していますので、ぜひ参考にしてください。
プロファイル NO.1 ～ ブログ記事 ～
ブログ記事のデータについて、以下のようにセキュリティルールを設定してみます。
1 2 3 4 5 6 7 8 9 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /articles/{article} { // 全てのユーザの読み書きを許可 allow read, write: if true; } } } |
上記のルールでは、全ての訪問者のデータの「読み書き」が許可されています。
公開ブログであれば、「読み込み」についての許可設定は必要となります。
しかし、「書き込み」については、誰でも記事の内容を変更・削除できる状態であり、適切なルールとは言えません。
認証付きユーザのみ「書き込み」を許可
「書き込み」については、以下のように認証付きのユーザのみが「書き込み」可能とするなどの調整が必要となります。
1 2 3 4 5 6 7 8 9 10 11 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /articles/{article} { // 全てのユーザの読み込みを許可 allow read: if true; // 認証されたユーザのみ書き込みを許可 allow write: if request.auth.uid != null; } } } |
プロファイル NO.2 ～ ユーザ情報 ～
ユーザ情報について、以下のようにセキュリティルールを設定してみます。
1 2 3 4 5 6 7 8 9 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /users/{userId} { // 認証されたユーザのみ読み書きを許可 allow read, write: if request.auth.uid != null; } } } |
一見、問題ないかのように見えますが、上記のルールでは、認証されているユーザであれば、ユーザ本人以外のユーザのデータの「読み書き」も可能な状態となっています。
認証されているユーザであれば誰でも、全てのユーザの情報を閲覧・変更・削除が可能であり、ユーザ情報の漏えいや改ざんにつながる可能性があります。
対策の１つとして、ユーザ本人だけが情報を取得・更新できるようにルールを設定することが挙げられるでしょう。
ユーザ本人だけ「読み書き」を許可
以下のようにルールを調整することで、ユーザ本人だけが情報を取得・更新できるようになります。
1 2 3 4 5 6 7 8 9 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /users/{userId} { // ユーザ本人の読み書きを許可 allow read, write: if request.auth.uid == userId; } } } |
プロファイル NO.3 ～ サーバプログラムのログ ～
サーバプログラムのログを Firestore に保存する場合、どのようにセキュリティルールを設定すれば良いでしょうか。
サーバからのアクセスのみで、ウェブ・モバイルクライアントからの「読み書き」は特に必要がない場合を考えます。
サーバプログラムのログについてセキュリティルールを設定
サーバプログラムのログについて、以下のようにセキュリティルールを設定してみます。
1 2 3 4 5 6 7 8 9 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /server_logs/{log} { // 全てのユーザの読み込みを許可 allow read: if true; } } } |
セキュリティルールは、ウェブ・モバイルクライアントからのアクセスに適用され、サーバからのアクセスには適用されません。
悪意あるユーザに、サーバプログラムのログを取得された場合、そこからセキュリティホールを発見、または推測される可能性があります。
そのため、クライアントで使用する事のないデータについては、不必要にアクセスを許可せずに、以下のように全てのアクセスを拒否してしまうのが安全です。
1 2 3 4 5 6 7 8 9 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /server_logs/{log} { // 全てのユーザの読み書きを拒否 allow read, write: if false; } } } |
セキュリティルール ～ テストのすすめ ～
以上のように、セキュリティルールが適切でない場合、意図しないユーザに情報が漏れてしまったり、データを改ざん・削除されてしまうといった事態が起こりえます。
Firestore を活用する上で、継続的にセキュリティルールの動作をチェックし、ルールを適正な状態に保つことが重要となります。
Firebase コンソールには、ルールの動作確認用のシミュレータが用意されています。
ですが、シミュレータを使うと、変更や調整のたびに毎回デプロイが必要だったり、設定の入力が必要だったりと手間がかかります。
また、ステージング環境では、手動操作でルールの確認もできますが、同様に面倒です。
そういった面倒や手間の回避する策として、テストによってセキュリティルールをチェックする事がおすすめです。
セキュリティルールをテストするメリット
セキュリティルールをテストするメリットをご紹介したいと思います！
ルールの確認が楽！
テストを用いたセキュリティルールのチェックでは、コマンドラインからテストを実行するだけで、セキュリティルールが適正な状態であるかどうかを確認することができます。
ファイルの監視機能があるテストツールであれば、ルールの変更に併せて自動でテストを再実施してくれるので、一段とスムーズにセキュリティルールの実装を進める事ができます。
また、ルールに不備があった場合には、テストのエラーメッセージによって不備のある箇所の推測・特定の助けとなるでしょう。
リグレッションテスト
慎重な設定・取り扱いが必要なセキュリティルールですが、テストによる保護があれば、気楽に追加調整や変更を加える事ができます。
同様の理由で、ルールの見通しをよくするために「ネスト記述で書き換える」、「カスタム関数を導入する」といった具合に、ルールのリファクタリングも気楽にできるようになります。
ルールのリファクタリングによってクリアなルールを維持することで、結果的にルールの設定漏れや設定ミスの防止につながります。
安全な環境を維持
「全てのアクセスを拒否する」ルールからスタートして、必要に合わせてアクセス許可のテストを追加していくことで、必要以上のアクセス許可が追加されることを継続的に防ぐことができます。
まとめ
以上、セキュリティルールの不備の危険性と、セキュリティルールをテストによって管理することのメリットを紹介しました。
最後に、簡単に今回の内容をまとめてみたいと思います。
- セキュリティルールの手抜きは危険！
- テストでセキュリティルールをチェック
- リグレッションテストで安全性を維持
- テストを導入すれば、気楽に調整ができる！
- テストを導入すれば、気楽にリファクタリングができる！
テストの導入は、多少の面倒はありますが、一度導入してしまえば、その後の開発の大きな助けとなります。
セキュリティルールのテストの導入については、以下の記事で詳細に解説しています。
興味がある方は、ぜひ読んでいただければ！
こちらの記事もオススメ！
書いた人はこんな人
- 「好きを仕事にするエンジニア集団」の（株）ライトコードです！
ライトコードは、福岡、東京、大阪の3拠点で事業展開するIT企業です。
現在は、国内を代表する大手IT企業を取引先にもち、ITシステムの受託事業が中心。
いずれも直取引で、月間PV数1億を超えるWebサービスのシステム開発・運営、インフラの構築・運用に携わっています。
システム開発依頼・お見積もり大歓迎！
また、現在「WEBエンジニア」「モバイルエンジニア」「営業」「WEBデザイナー」「WEBディレクター」を積極採用中です！
インターンや新卒採用も行っております。
以下よりご応募をお待ちしております！
https://rightcode.co.jp/recruit
ITエンタメ10月 13, 2023Netflixの成功はレコメンドエンジン？- ライトコードの日常8月 30, 2023退職者の最終出社日に密着してみた！
- ITエンタメ8月 3, 2023世界初の量産型ポータブルコンピュータを開発したのに倒産!?アダム・オズボーン
- ITエンタメ7月 14, 2023【クリス・ワンストラス】GitHubが出来るまでとソフトウェアの未来
関連記事
採用情報
\ あの有名サービスに参画!? /
バックエンドエンジニア
\ クリエイティブの最前線 /
フロントエンドエンジニア
\ 世界を変える…！ /
Androidエンジニア
\ みんなが使うアプリを創る /
iOSエンジニア
