1. HOME
  2. ブログ
  3. IT技術
  4. Firestore セキュリティルール ~入門編~

Firestore セキュリティルール ~入門編~

Firestore セキュリティルール

なにかと便利な「Firestore(ファイアストア)

ですが、セキュリティルールの設定を怠ると「データが改ざんされる」「削除される」、といった事態に発展する可能性があります。

本記事では、サンプルを交えつつ、セキュリティルールの基本的な構成や設定の方法について解説していきたいと思います!

簡単な流れ

本記事では、以下のような流れで解説を進めていきます!

  1. セキュリティルールの簡単なサンプルとともに、基本的な構成を解説
  2. セキュリティルールの主要な要素である matchステートメントと allow式について解説
  3. セキュリティルールの気になるところを Q & A方式で解説

セキュリティルールの基本的な構成

まずは、セキュリティルールの簡単なサンプルとともに、基本的な構成について解説したいと思います。

セキュリティルールの基本的な構成

セキュリティルールの基本的な構成は、以下のような形式となります。

rules_version

セキュリティルールのバージョンを指定する部分です。

2019年5月以降から、セキュリティルールの「バージョン2」が使用可能になりました。

コレクション グループ クエリを使う場合は「バージョン2」を指定して、コレクション グループ クエリ用のセキュリティルールを設定する必要があります。

特にバージョンの指定がない場合は「バージョン1」となります。

service cloud.firestore

対象サービスを指定する部分です。

他プロダクト(Cloud Storageなど)との、ルールの競合を防ぐための設定です。

match /databases/{database}/documents

プロジェクト内の、Firestore データベースを指定する部分です。

現在、各プロジェクトには (default) というデータベースが1つだけあるので、database変数には (default) が代入されます。

match ステートメント

ドキュメントのパスを指定する部分です。

指定先はドキュメントのみで、コレクションを指定する事はできません。

上記の例の場合、 match /users/{user} の部分で、usersコレクションのドキュメントを指定しています。

{user} の部分は、ワイルドカード表記を使用してます。(※ワイルドカードについては後述いたします)

allow 式

読み書きの許可条件を指定する部分です。

上記の例の場合、 allow read: if true; の部分で読み込みを許可。

allow write: if false; の部分で、書き込みを拒否しています。

matchステートメント 入門

複数のサブコレクションのセキュリティルールを記述する際、全てのサブコレクションに対して、ドキュメントパスの全体を記述するのは面倒だと思います。

matchステートメントはネスト記述が使える!

そのような場合は、以下のようにネスト記述」を使うと便利です。

ここで、「favoritesサブコレクション」と、「propertiesサブコレクション」に対する「matchステートメント」は、外側の matchステートメント(ここではusersコレクション)のパスからの、相対パスとなります。

よって、上記のセキュリティルールと、以下のセキュリティルールは同等のものとなります。

サブコレクションが2つくらいであれば、それほど面倒ではありません。

ですが、3つ4つとルールが増えてくると、「ネスト記述」を使う方が楽になってきます。

また、共通部分を「ネスト記述」を使って括りだしておくと、ルール全体の見通しがよくなり、ルールの設定漏れ防止にもつながります。

matchステートメントはワイルドカードが使える!

以下のように、matchステートメントではワイルドカードが利用できます

① 特定のドキュメントを指定

①のルールでは、ワイルドカードを使用せずに、「vegetablesコレクション」の carrotドキュメントのみの読み書きを許可しています。

「vegetablesコレクション」の、carrotドキュメント以外の読み書きは拒否されます。

② ワイルドカードでfruitsコレクションの任意のドキュメントを指定

②のルールでは、ワイルドカード {fruit} を使って、「fruitsコレクション」の任意のドキュメントの読み書きを許可しています。

「fruitsコレクション」の、任意のドキュメントの読み書きが可能です。

matchステートメントは再帰ワイルドカードが使える!

深い階層のサブコレクションのルールを記述する場合、各階層のサブコレクション全てについてルールを記述するのは面倒だと思います。

そのような場合、以下のように「再帰ワイルドカード構文 {document=**} 」を使うと便利です。

上記のルールは、「usersコレクション」内のドキュメントに加え、「usersコレクション」以下のサブコレクションのドキュメントにも適用されます。

たとえば、 /users/{user}/favorites/users/{user}/favorites/{favorite}/memos などのサブコレクションにも、上記のルールが適用されます。

document変数は、ルールが適用されたドキュメントに対応する値となります。

たとえば、ドキュメント /users/yamada/favorites/apple についての判定では、document変数の値は yamada/favorites/apple となります。

再帰ワイルドカードの補足 ~ バージョン1とバージョン2の違い ~

「バージョン1」と「バージョン2」で、再帰ワイルドカードの動作が異なります。

match /users/{user}/{document=**} のような matchステートメントがあった場合

たとえば、 match /users/{user}/{document=**} のような matchステートメントがあった場合、「バージョン2」では usersコレクションと、usersコレクションのサブコレクションに対してルールが適用されます。

対して「バージョン1」では、usersコレクションにはルールが適用されません。

「バージョン1」で usersコレクションにルールを適用する場合は、 match /users/{document=**} のように matchステートメントを記述する必要があります。

再帰ワイルドカードを配置

「バージョン2」では、 match /{path=**}/favorites/{favorite} のように任意の場所に再帰ワイルドカードを配置できます。

一方「バージョン1」では、matchステートメントの最後にだけ配置することができます。

コレクション グループ クエリを使用する場合は、「バージョン2」を使用する必要があります。

今から Firestore を使い始める場合は、セキュリティルールは「バージョン2」を使う事をオススメします!

allow式 入門

「allow式」は、以下のようなフォーマットで記述します。

[アクセスタイプ] の部分で、「read」や「write」のようなアクセスタイプを指定します。

[条件] の部分で、アクセスの許可条件を指定します。

[条件] 部分で指定した条件が、 true の場合は指定のアクセスが許可されます。

allow式で指定できるアクセスタイプ

allow式では、read、write ルールに加えて、readルールを分割した「get」「list」や、writeルールを分割した「create」「update」「 delete」を指定することができます。

セキュリティルールのここが気になる!? ~Q & A コーナー~

セキュリティルールについて、気になるところを Q&A でまとめてみました!

セキュリティルールで指定していないアクセスは許可?拒否?

セキュリティルールで指定されていないアクセスは拒否されます。

以下のようなルールの場合、usersコレクションの readアクセスのみが許可されます。

そして、usersコレクションの writeアクセスと users以外のコレクションへのアクセスは拒否されます。

1つのドキュメントが、複数のmatchステートメントと一致するとどうなる!?

いずれかの「allow式」の条件が true と評価されると、アクセスが許可されます。

たとえば、以下のようなルールの場合、usersコレクションの読み書きが許可されます。

上記のルールでは、1つ目のルールで usersコレクションの読み書きを拒否しています。

2つ目のルールで、usersコレクションのサブコレクションと、usersコレクションの読み書きを許可しています。

usersコレクションに対するルールが競合していますが、この場合は許可設定が優先されて、usersコレクションへの読み書きが許可されます。

プロジェクトディレクトリのセキュリティルールをデプロイすると、Firebaseコンソールで設定したルールはどうなる?

デプロイしたプロジェクトディレクトリのセキュリティルールで上書きされます。

Firebase CLI を使ってルールをデプロイする場合は、ルールの定義・更新をプロジェクトディレクトリのルールに統一することをオススメします!

もし Firebaseコンソールでルールを編集する場合は、その都度、プロジェクトディレクトリのルールも更新してください。

まとめ

以上、セキュリティルールの基本的な構成やmatchステートメント、allow式の記述の仕方についてサンプルルールを交えて解説しました。

最後に、簡単に今回の内容をまとめてみたいと思います!

  1. セキュリティルールは大事
  2. 基本はmatchとallowだけ
  3. matchステートメントはワイルドカードやネスト記述、再帰ワイルドカードが使える
  4. readアクセスはgetとlistに分割できる
  5. writeアクセスはcreate, update, deleteに分割できる
  6. 今からはじめるならバージョンは2がおすすめ

今回ご紹介した内容をもとに、セキュリティルールの設定を行っていただければと思います!

(株)ライトコードは、WEB・アプリ・ゲーム開発に強い、「好きを仕事にするエンジニア集団」です。
システム開発依頼・お見積もりはこちらまでお願いします。
また、技術が大好きなエンジニアを積極採用中です!詳しくはこちらをご覧ください。

※現在、多数のお問合せを頂いており、返信に、多少お時間を頂く場合がございます。

こちらの記事もオススメ!

ライトコードよりお知らせ

にゃんこ師匠にゃんこ師匠
システム開発のご相談やご依頼はこちら
ミツオカミツオカ
ライトコードの採用募集はこちら
にゃんこ師匠にゃんこ師匠
社長と一杯飲みながらお話してみたい方はこちら
ミツオカミツオカ
フリーランスエンジニア様の募集はこちら
にゃんこ師匠にゃんこ師匠
その他、お問い合わせはこちら
ミツオカミツオカ
   
お気軽にお問い合わせください!せっかくなので、別の記事もぜひ読んでいって下さいね!

一緒に働いてくれる仲間を募集しております!

ライトコードでは、仲間を募集しております!

当社のモットーは「好きなことを仕事にするエンジニア集団」「エンジニアによるエンジニアのための会社」。エンジニアであるあなたの「やってみたいこと」を全力で応援する会社です。

また、ライトコードは現在、急成長中!だからこそ、あなたにお任せしたいやりがいのあるお仕事は沢山あります。「コアメンバー」として活躍してくれる、あなたからのご応募をお待ちしております!

なお、ご応募の前に、「話しだけ聞いてみたい」「社内の雰囲気を知りたい」という方はこちらをご覧ください。

ライトコードでは一緒に働いていただける方を募集しております!

採用情報はこちら

書いた人はこんな人

ライトコードメディア編集部
ライトコードメディア編集部
「好きなことを仕事にするエンジニア集団」の(株)ライトコードのメディア編集部が書いている記事です。

関連記事

採用情報

\ あの有名サービスに参画!? /

バックエンドエンジニア

\ クリエイティブの最前線 /

フロントエンドエンジニア

\ 世界はお前の手の中に・・・ /

モバイルエンジニア

\ サービスの守り神! /

インフラエンジニア