Firestore セキュリティルール ～入門編～
2021.12.20
Firestore セキュリティルール
なにかと便利な「Firestore（ファイアストア）」
ですが、セキュリティルールの設定を怠ると「データが改ざんされる」「削除される」、といった事態に発展する可能性があります。
本記事では、サンプルを交えつつ、セキュリティルールの基本的な構成や設定の方法について解説していきたいと思います！
簡単な流れ
本記事では、以下のような流れで解説を進めていきます！
- セキュリティルールの簡単なサンプルとともに、基本的な構成を解説
- セキュリティルールの主要な要素である matchステートメントと allow式について解説
- セキュリティルールの気になるところを Q & A方式で解説
セキュリティルールの基本的な構成
まずは、セキュリティルールの簡単なサンプルとともに、基本的な構成について解説したいと思います。
セキュリティルールの基本的な構成
セキュリティルールの基本的な構成は、以下のような形式となります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | // セキュリティルールのバージョンを指定 rules_version = '2'; // 対象サービスを指定 service cloud.firestore { // プロジェクト内のFirestoreデータベースを指定 match /databases/{database}/documents { // ドキュメントパスを指定 match /users/{user} { // 読み込みを許可 allow read: if true; // 書き込みを拒否 allow write: if false; } } } |
rules_version
セキュリティルールのバージョンを指定する部分です。
2019年5月以降から、セキュリティルールの「バージョン２」が使用可能になりました。
コレクション グループ クエリを使う場合は「バージョン２」を指定して、コレクション グループ クエリ用のセキュリティルールを設定する必要があります。
特にバージョンの指定がない場合は「バージョン１」となります。
service cloud.firestore
対象サービスを指定する部分です。
他プロダクト（Cloud Storageなど）との、ルールの競合を防ぐための設定です。
match /databases/{database}/documents
プロジェクト内の、Firestore データベースを指定する部分です。
現在、各プロジェクトには (default) というデータベースが１つだけあるので、database変数には (default) が代入されます。
match ステートメント
ドキュメントのパスを指定する部分です。
指定先はドキュメントのみで、コレクションを指定する事はできません。
上記の例の場合、 match /users/{user} の部分で、usersコレクションのドキュメントを指定しています。
{user} の部分は、ワイルドカード表記を使用してます。（※ワイルドカードについては後述いたします）
allow 式
読み書きの許可条件を指定する部分です。
上記の例の場合、 allow read: if true; の部分で読み込みを許可。
allow write: if false; の部分で、書き込みを拒否しています。
matchステートメント 入門
複数のサブコレクションのセキュリティルールを記述する際、全てのサブコレクションに対して、ドキュメントパスの全体を記述するのは面倒だと思います。
matchステートメントはネスト記述が使える！
そのような場合は、以下のように「ネスト記述」を使うと便利です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /users/{user} { // favoritesサブコレクションを指定 match /favorites/{favorite} { allow read, write: if true; } // propertiesサブコレクションを指定 match /properties/{property} { allow read, write: if true; } } } } |
ここで、「favoritesサブコレクション」と、「propertiesサブコレクション」に対する「matchステートメント」は、外側の matchステートメント（ここではusersコレクション）のパスからの、相対パスとなります。
よって、上記のセキュリティルールと、以下のセキュリティルールは同等のものとなります。
1 2 3 4 5 6 7 8 9 10 11 12 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /users/{user}/favorites/{favorite} { allow read, write: if true; } match /users/{user}/properties/{property} { allow read, write: if true; } } } |
サブコレクションが２つくらいであれば、それほど面倒ではありません。
ですが、３つ４つとルールが増えてくると、「ネスト記述」を使う方が楽になってきます。
また、共通部分を「ネスト記述」を使って括りだしておくと、ルール全体の見通しがよくなり、ルールの設定漏れ防止にもつながります。
matchステートメントはワイルドカードが使える！
以下のように、matchステートメントではワイルドカードが利用できます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { // ① 特定のドキュメントを指定 match /vegetables/carrot { allow read, write: if true; } // ② ワイルドカードでfruitsコレクションの任意のドキュメントを指定 match /fruits/{fruit} { allow read, write: if true; } } } |
① 特定のドキュメントを指定
①のルールでは、ワイルドカードを使用せずに、「vegetablesコレクション」の carrotドキュメントのみの読み書きを許可しています。
「vegetablesコレクション」の、carrotドキュメント以外の読み書きは拒否されます。
② ワイルドカードでfruitsコレクションの任意のドキュメントを指定
②のルールでは、ワイルドカード {fruit} を使って、「fruitsコレクション」の任意のドキュメントの読み書きを許可しています。
「fruitsコレクション」の、任意のドキュメントの読み書きが可能です。
matchステートメントは再帰ワイルドカードが使える！
深い階層のサブコレクションのルールを記述する場合、各階層のサブコレクション全てについてルールを記述するのは面倒だと思います。
そのような場合、以下のように「再帰ワイルドカード構文 {document=**} 」を使うと便利です。
1 2 3 4 5 6 7 8 9 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { // usersコレクション以下の全てのドキュメントに対するルール match /users/{document=**} { allow read, write: if true; } } } |
上記のルールは、「usersコレクション」内のドキュメントに加え、「usersコレクション」以下のサブコレクションのドキュメントにも適用されます。
たとえば、 /users/{user}/favorites や /users/{user}/favorites/{favorite}/memos などのサブコレクションにも、上記のルールが適用されます。
document変数は、ルールが適用されたドキュメントに対応する値となります。
たとえば、ドキュメント /users/yamada/favorites/apple についての判定では、document変数の値は yamada/favorites/apple となります。
再帰ワイルドカードの補足 ～ バージョン１とバージョン２の違い ～
「バージョン１」と「バージョン２」で、再帰ワイルドカードの動作が異なります。
match /users/{user}/{document=**} のような matchステートメントがあった場合
たとえば、 match /users/{user}/{document=**} のような matchステートメントがあった場合、「バージョン２」では usersコレクションと、usersコレクションのサブコレクションに対してルールが適用されます。
対して「バージョン１」では、usersコレクションにはルールが適用されません。
「バージョン１」で usersコレクションにルールを適用する場合は、 match /users/{document=**} のように matchステートメントを記述する必要があります。
再帰ワイルドカードを配置
「バージョン２」では、 match /{path=**}/favorites/{favorite} のように任意の場所に再帰ワイルドカードを配置できます。
一方「バージョン１」では、matchステートメントの最後にだけ配置することができます。
コレクション グループ クエリを使用する場合は、「バージョン２」を使用する必要があります。
今から Firestore を使い始める場合は、セキュリティルールは「バージョン２」を使う事をオススメします！
allow式 入門
「allow式」は、以下のようなフォーマットで記述します。
1 | allow [アクセスタイプ]: if [条件]; |
[アクセスタイプ] の部分で、「read」や「write」のようなアクセスタイプを指定します。
[条件] の部分で、アクセスの許可条件を指定します。
[条件] 部分で指定した条件が、 true の場合は指定のアクセスが許可されます。
allow式で指定できるアクセスタイプ
allow式では、read、write ルールに加えて、readルールを分割した「get」「list」や、writeルールを分割した「create」「update」「 delete」を指定することができます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /vegetables/{vegetable} { // ドキュメントの取得を許可 allow read: if true; // ドキュメントの追加・更新・削除を許可 allow write: if true; } // readルールはget, listルールに分ける事ができます match /fruits/{fruit} { // 単一ドキュメントの取得を許可 allow get: if true; // 複数ドキュメント(クエリやコレクション)の取得を許可 allow list: if true; } // writeルールはcreate, update, deleteルールに分ける事ができます match /fruits/{fruit} { // 新規ドキュメントの追加を許可 allow create: if true; // 既存ドキュメントの更新を許可 allow update: if true; // ドキュメントの削除を許可 allow delete: if true; } } } |
セキュリティルールのここが気になる！？ ～Q & A コーナー～
セキュリティルールについて、気になるところを Q&A でまとめてみました！
セキュリティルールで指定していないアクセスは許可？拒否？
セキュリティルールで指定されていないアクセスは拒否されます。
以下のようなルールの場合、usersコレクションの readアクセスのみが許可されます。
そして、usersコレクションの writeアクセスと users以外のコレクションへのアクセスは拒否されます。
1 2 3 4 5 6 7 8 9 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { // usersコレクションの読み込みを許可 match /users/{user} { allow read: if true; } } } |
１つのドキュメントが、複数のmatchステートメントと一致するとどうなる！？
いずれかの「allow式」の条件が true と評価されると、アクセスが許可されます。
たとえば、以下のようなルールの場合、usersコレクションの読み書きが許可されます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { // usersコレクションの読み書きを拒否 match /users/{user} { allow read, write: if false; } // usersコレクションとサブコレクションの読み書きを許可 match /users/{users}/{document=**} { allow read, write: if true; } } } |
上記のルールでは、１つ目のルールで usersコレクションの読み書きを拒否しています。
２つ目のルールで、usersコレクションのサブコレクションと、usersコレクションの読み書きを許可しています。
usersコレクションに対するルールが競合していますが、この場合は許可設定が優先されて、usersコレクションへの読み書きが許可されます。
プロジェクトディレクトリのセキュリティルールをデプロイすると、Firebaseコンソールで設定したルールはどうなる？
デプロイしたプロジェクトディレクトリのセキュリティルールで上書きされます。
Firebase CLI を使ってルールをデプロイする場合は、ルールの定義・更新をプロジェクトディレクトリのルールに統一することをオススメします！
もし Firebaseコンソールでルールを編集する場合は、その都度、プロジェクトディレクトリのルールも更新してください。
まとめ
以上、セキュリティルールの基本的な構成やmatchステートメント、allow式の記述の仕方についてサンプルルールを交えて解説しました。
最後に、簡単に今回の内容をまとめてみたいと思います！
- セキュリティルールは大事
- 基本はmatchとallowだけ
- matchステートメントはワイルドカードやネスト記述、再帰ワイルドカードが使える
- readアクセスはgetとlistに分割できる
- writeアクセスはcreate, update, deleteに分割できる
- 今からはじめるならバージョンは２がおすすめ
今回ご紹介した内容をもとに、セキュリティルールの設定を行っていただければと思います！
こちらの記事もオススメ！
書いた人はこんな人
- 「好きを仕事にするエンジニア集団」の（株）ライトコードです！
ライトコードは、福岡、東京、大阪の3拠点で事業展開するIT企業です。
現在は、国内を代表する大手IT企業を取引先にもち、ITシステムの受託事業が中心。
いずれも直取引で、月間PV数1億を超えるWebサービスのシステム開発・運営、インフラの構築・運用に携わっています。
システム開発依頼・お見積もり大歓迎！
また、現在「WEBエンジニア」「モバイルエンジニア」「営業」「WEBデザイナー」「WEBディレクター」を積極採用中です！
インターンや新卒採用も行っております。
以下よりご応募をお待ちしております！
https://rightcode.co.jp/recruit
ライトコードの日常12月 1, 2023ライトコードクエスト〜東京オフィス歴史編〜- ITエンタメ10月 13, 2023Netflixの成功はレコメンドエンジン？
- ライトコードの日常8月 30, 2023退職者の最終出社日に密着してみた！
- ITエンタメ8月 3, 2023世界初の量産型ポータブルコンピュータを開発したのに倒産!?アダム・オズボーン
関連記事
採用情報
\ あの有名サービスに参画!? /
バックエンドエンジニア
\ クリエイティブの最前線 /
フロントエンドエンジニア
\ 世界を変える…！ /
Androidエンジニア
\ みんなが使うアプリを創る /
iOSエンジニア
