Firebase Auth & Realtime Database Apps · レッスン

セキュリティルール構文の理解

アクセス権限を定義するためのFirebase Realtime Database Security Rulesの構文と構造を理解します。

「セキュリティルール構文の理解」はCoddyKit上の無料Firebase Auth & Realtime Database Appsレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはFirebase Auth & Realtime Database Apps学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Firebase Auth & Realtime Database Appsコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Security Rules?

Welcome to Realtime Database Security Rules! These rules are super important for keeping your data safe and controlling who can do what in your Firebase app.

Think of them as bouncers for your database: they check every request to read, write, or update data, and decide if it's allowed or not.

Your Rules File

Firebase Realtime Database Security Rules are defined in a JSON file, usually named rules.json. You'll upload this file to your Firebase project.

The entire set of rules is wrapped under a top-level "rules" key, like this:

{
  "rules": {
    // Your security rules go here!
  }
}

Default Open Rules

When you first create a Realtime Database, Firebase often provides a very open set of rules. This allows anyone to read and write data, which is great for getting started quickly, but terrible for production!

These rules look like this:

{
  "rules": {
    ".read": "true",
    ".write": "true"
  }
}

Targeting Data Paths

Rules are applied based on the path to your data. You nest rules within the "rules" object to target specific parts of your database, just like folders in a file system.

For example, to set rules for /users or /messages:

{
  "rules": {
    "users": {
      // Rules for data under /users
    },
    "messages": {
      // Rules for data under /messages
    }
  }
}

Basic Read Permissions

The ".read" rule determines who can retrieve data from a specific path. If a read request matches a path with ".read": "true", it's allowed. If it's "false", it's denied.

Here's how you might set read permissions:

{
  "rules": {
    "publicPosts": {
      ".read": "true" // Anyone can read blog posts
    },
    "secretDocs": {
      ".read": "false" // No one can read secret documents
    }
  }
}

Basic Write Permissions

Similarly, the ".write" rule controls who can create, update, or delete data at a given path. Setting it to "true" allows writes, and "false" denies them.

Let's look at some write rule examples:

{
  "rules": {
    "guestbook": {
      ".write": "true" // Anyone can sign the guestbook
    },
    "adminSettings": {
      ".write": "false" // No one can change admin settings yet
    }
  }
}

Combining Read & Write

You can define both ".read" and ".write" rules for the same path. Firebase evaluates them independently.

For example, to make a path readable by everyone but writable by no one (yet):

{
  "rules": {
    "announcements": {
      ".read": "true",  // Everyone can see announcements
      ".write": "false" // No one can post new announcements
    }
  }
}

Dynamic Paths with Wildcards

What if you have many items under a path, like individual user profiles (/users/user123, /users/user456)? You don't want to write a rule for each one!

Use a wildcard variable, prefixed with $, to match any child node. This variable can then be used within the rule itself.

{
  "rules": {
    "profileData": {
      "$userId": {
        ".read": "true",  // Anyone can read any user's profile
        ".write": "false" // But no one can edit them yet
      }
    }
  }
}

`auth` & `data`: Rule Helpers

When writing more advanced rules, you'll often need to check who is making the request or what data already exists. Firebase provides special variables for this:

auth: Contains information about the currently authenticated user (if any).
data: Refers to the data that already exists at the path being accessed.
newData: Refers to the data being written (only for write/validate rules).

These let you create smart rules, like "only the owner can edit their profile." We'll dive into these in upcoming lessons!

Syntax Check

Given the Firebase Realtime Database Security Rules below, which statement is true?

{
  "rules": {
    "posts": {
      ".read": "true",
      "comments": {
        ".write": "false"
      }
    },
    "users": {
      "$userId": {
        ".read": "true"
      }
    }
  }
}

Lesson Summary

Great job! In this lesson, we covered the foundational syntax of Firebase Realtime Database Security Rules:

Rules live in a rules.json file.
Rules are nested to target specific data paths.
".read" and ".write" control read and write access.
Wildcards ($variable) make rules dynamic for child nodes.
You got a sneak peek at context variables like auth and data.

Next, we'll dive deeper into using these rules for user-based access control!

よくある質問

「セキュリティルール構文の理解」レッスンは無料ですか？

はい。「セキュリティルール構文の理解」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Firebase Auth & Realtime Database Appsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Firebase Auth & Realtime Database Appsコースには全4レッスンが含まれています。

「セキュリティルール構文の理解」で何を学びますか？

アクセス権限を定義するためのFirebase Realtime Database Security Rulesの構文と構造を理解します。ブラウザで直接実行するハンズオンコードでFirebase Auth & Realtime Database Appsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Firebase Auth & Realtime Database Appsを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのFirebase Auth & Realtime Database Appsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「セキュリティルール構文の理解」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このFirebase Auth & Realtime Database Appsレッスンでコードを書いて実行できますか？

はい。すべてのFirebase Auth & Realtime Database Appsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Firebase Auth & Realtime Database Appsに戻る