Firebase 即時資料庫安全性規則會決定誰具有讀取和寫入權限 資料庫、資料結構和存在的索引。這些規則會儲存在 Firebase 伺服器上，並隨時自動強制執行。每次閱讀 且只有在規則允許時，才會完成寫入要求。根據預設，您的規則不會允許任何人存取資料庫。這麼做是為了保護您的 讓您有更多時間自訂規則或設定 驗證。
即時資料庫安全性規則採用類似 JavaScript 的語法，共有四種類型：
| 規則類型 | |
|---|---|
| .read | 說明使用者是否可以讀取資料，以及何時允許讀取資料。 |
| .write | 說明是否允許寫入資料，以及何時允許寫入資料。 |
| .validate | 定義格式正確的值會呈現的樣子 (無論是否有錯誤) 含有子屬性和資料類型 |
| .indexOn | 指定要建立索引的子項，以支援排序和查詢功能。 |
Realtime Database 安全性總覽
Firebase Realtime Database 提供一組完整的工具，可用來管理 確保應用程式安全無虞這些工具可讓您輕鬆驗證使用者 並驗證輸入內容
相較於採用其他多種技術堆疊的應用程式，Firebase 應用程式會執行更多用戶端程式碼。因此，我們處理安全性的做法可能與您習慣的方式有些不同。
驗證
保護應用程式安全的第一步通常是識別使用者。這項程序稱為驗證。 您可以使用 Firebase 驗證 這樣才能讓使用者登入您的應用程式Firebase 驗證 內建支援常見驗證方法，例如 Google 和 Facebook、電子郵件和密碼登入、匿名登入等多種功能。
使用者身分是重要的安全概念。每位使用者都有不同的 有時候也會有不同的能力舉例來說，在即時通訊應用程式中，每則訊息都會與建立該訊息的使用者建立關聯。使用者也可以刪除自己的訊息，但無法刪除其他使用者發布的訊息。
授權
辨識使用者只是安全性措施的一部分。瞭解他們的背景後
因此，您需要採取一種方法來控管
對資料庫資料的存取權。即時資料庫安全性規則
可讓您控管每位使用者的存取權例如，這裡是一組
允許所有人讀取 /foo/ 路徑，但不允許
一是寫入該物件：
{
"rules": {
"foo": {
".read": true,
".write": false
}
}
}
.read 和 .write 規則會層層套用，因此這個規則集會授予讀取權限，可存取路徑 /foo/ 中的所有資料，以及 /foo/bar/baz 等更深層的路徑。請注意，.read 和
資料庫中的 .write 規則範圍會覆寫更深層的規則，因此
本例仍會授予「/foo/bar/baz」的讀取權限
即使 /foo/bar/baz 路徑中的規則評估為 false 也一樣。
即時資料庫安全性規則包括
內建變數
以及功能
參照其他路徑、伺服器端時間戳記、驗證資訊
等等。以下舉例說明的規則將寫入權限授予
向「/users/<uid>/」進行驗證的使用者，其中 <uid>為
透過 Firebase Authentication 取得的使用者 ID。
{
"rules": {
"users": {
"$uid": {
".write": "$uid === auth.uid"
}
}
}
}
驗證資料
Firebase Realtime Database 是無結構定義。這樣一來，您就能在開發過程中輕鬆變更內容，但一旦應用程式可供發布，資料就必須保持一致。規則語言包含 .validate 規則，可讓您使用 .read 和 .write 規則使用的相同運算式套用驗證邏輯。唯一的差別是
「驗證規則不會串聯」，因此所有相關
驗證規則必須評估為 true，才能允許寫入。
這些規則會強制規定寫入 /foo/ 的資料必須是長度少於 100 個字元的字串：
{
"rules": {
"foo": {
".validate": "newData.isString() && newData.val().length < 100"
}
}
}
驗證規則可存取 .read 和 .write 規則的所有內建函式和變數。別擔心！您可以使用
來建立驗證規則
以及使用者身分、伺服器時間等等
定義資料庫索引
Firebase Realtime Database 允許排序及查詢資料。如果資料量較小，資料庫會支援臨時查詢，因此開發期間通常不需要索引。不過，在推出應用程式之前，請務必為所有查詢指定索引，確保這些查詢在應用程式擴充時仍能正常運作。
索引是透過 .indexOn 規則指定。以下是索引宣告範例，會為恐龍清單的高度和長度欄位建立索引：
{
"rules": {
"dinosaurs": {
".indexOn": ["height", "length"]
}
}
}