Firestore、Storage、Realtime Database向けに、本人だけが扱えるデータ、公開読み取り、管理者ロール、入力検証のコピーできるルール例と、そのテスト方法を紹介します。
Firebaseのセキュリティルールは、アプリ内の各データを誰が読み書きできるかを決めます。Firestoreのファイルは必ず rules_version = '2' で始め、request.auth が設定されている場合にのみアクセスを許可し、request.auth.uid をドキュメントの所有者と比較し、受け取ったフィールドを request.resource.data で確認します。デプロイ前にエミュレーターでテストしましょう。
各プロダクトでよく使う変数
アプリ、ショップ、会員エリアのデータをFirebaseに保存しているなら、顧客の記録と、プロジェクトの公開設定を手にした誰かとの間にあるのはルールだけです。以下のレシピは、多くの小規模なアプリに必要なケースを扱っています。プロダクトで絞り込み、1つコピーして、コレクション名を自分のものに合わせて変更してください。
データベースを作成するときに選べる2つの初期設定の1つです。Firebaseはテストモードについて、使い始めには便利だが、誰でもデータを読み取り、上書きできる状態になると説明しています。本番モードでは、ルールを書くまでモバイルやウェブのクライアントからの読み書きがすべて拒否されます。
request.time < timestamp.date(2026, 11, 1) のように、request.time を固定の日付と比較している条件がないか探してください。その日付を過ぎると、すべてのリクエストが失敗します。日付を先に延ばすのではなく、本来のルールに置き換えましょう。
Firebaseのドキュメントでは、単一ドキュメントのリクエストとクエリではドキュメントアクセスの呼び出しが10回まで、複数ドキュメントの読み取り、トランザクション、バッチ書き込みでは20回までという上限が示されています。超えると permission denied エラーになります。
いいえ。ルールはモバイルやウェブのクライアントからのリクエストを守るものです。Firebaseは、サーバー用クライアントライブラリはCloud Firestoreのセキュリティルールをすべて回避すると明記しているため、サーバーのコードでは別途入力を確認してください。
firebase emulators:start --only firestore でエミュレーターを起動し、@firebase/rules-unit-testing パッケージでテストを書きます。許可される操作には assertSucceeds、ブロックされる操作には assertFails を使います。
以下のパターンはスタータープロジェクトやチュートリアルによく出てきます。どれもデータを開けっ放しにします。
危険なルールと、より安全な置き換え
Firestoreエミュレーターを実行し、所有者は書き込めて、他人は書き込めないことを確認します。
デモ用のプロジェクトIDを使うため、本番のデータベースには何も届きません。firebase emulators:start --only firestore を実行している間に実行してください。
各ユーザーは、IDが自分のユーザーIDと一致するドキュメントだけを読み取り、編集できます。
商品カタログは誰でも読めますが、変更できるのはプロフィールのロールが admin のユーザーだけです。
顧客は自分自身の注文だけを、正の合計額と既知のステータスで作成でき、作成後は編集できません。
プロフィールの編集は、role フィールドがまったく変わらない場合にのみ許可されます。
ファイルは各ユーザーのフォルダーに保存されます。アップロードは5MB未満の画像に限られ、ログインしていれば誰でも閲覧できます。
Realtime DatabaseのルールはJSONです。$uid がキーを受け取り、newData が書き込まれる値です。
表示するレシピ
すべてのプロダクト
Cloud Firestore
Cloud Storage
Realtime Database
{n} 件のレシピを表示中
無料で始める · クレジットカード不要