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 的規則評估結果為 false，這個範例仍會授予 /foo/bar/baz 的讀取權。
Realtime Database 安全性規則包含
內建變數
和函式，可供您參照其他路徑、伺服器端時間戳記、驗證資訊等。以下是規則範例，可授予已驗證使用者對 /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 規則指定。以下是索引宣告範例，會為恐龍清單的 height 和 length 欄位建立索引：
{
"rules": {
"dinosaurs": {
".indexOn": ["height", "length"]
}
}
}