以下是我们在 I/O 大会上宣布的所有内容，从新的 Firebase Studio 功能到集成 AI 的更多方式，内容非常丰富。阅读博客。

Эта страница переведена с помощью Cloud Translation API.

Избегайте небезопасных правил

Используйте это руководство, чтобы понять распространенные уязвимости в конфигурациях Firebase Security Rules , просмотреть и лучше защитить собственные правила, а также протестировать свои изменения перед их развертыванием.

Если вы получили предупреждение о том, что ваши данные не защищены должным образом, просмотрите эти часто допускаемые ошибки и обновите все уязвимые правила.

Доступ к Firebase Security Rules

Чтобы просмотреть существующие Rules , используйте Firebase CLI или консоль Firebase . Убедитесь, что вы редактируете правила одним и тем же способом, чтобы избежать ошибочной перезаписи обновлений. Если вы не уверены, отражают ли ваши локально заданные правила последние обновления, в консоли Firebase всегда отображается последняя развёрнутая версия Firebase Security Rules .

Чтобы получить доступ к правилам из консоли Firebase , выберите проект, затем перейдите в Realtime Database , Cloud Firestore или Storage . Перейдя в нужную базу данных или хранилище, нажмите «Правила» .

Чтобы получить доступ к правилам из Firebase CLI, перейдите к файлу правил, указанному в файле firebase.json .

Понимание Firebase Security Rules

Firebase Security Rules защищают ваши данные от злоумышленников. При создании экземпляра базы данных или контейнера Cloud Storage в консоли Firebase вы можете либо запретить доступ всем пользователям ( режим Locked ), либо предоставить доступ всем пользователям ( режим Test ). Хотя на этапе разработки вам может потребоваться более открытая конфигурация, обязательно уделите время правильной настройке правил и защите данных перед развертыванием приложения.

При разработке приложения и тестировании различных конфигураций правил используйте один из локальных эмуляторов Firebase для запуска приложения в локальной среде разработки.

Распространенные сценарии с небезопасными правилами

Rules вы могли настроить по умолчанию или которые вы использовали при первоначальной разработке приложения, следует пересмотреть и обновить перед его развертыванием. Убедитесь, что вы надёжно защищаете данные пользователей, избегая следующих распространённых ошибок.

Открытый доступ

При настройке проекта Firebase вы, возможно, установили правила, разрешающие открытый доступ во время разработки. Вы можете думать, что вы единственный пользователь вашего приложения, но если вы его развернули, оно доступно в интернете. Если вы не аутентифицируете пользователей и не настраиваете правила безопасности, любой, кто угадает идентификатор вашего проекта, сможет украсть, изменить или удалить данные.

Не рекомендуется: доступ на чтение и запись для всех пользователей.

Cloud Firestore

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this ruleset in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Realtime Database

{
  // Allow read/write access to all users under any conditions
  // Warning: **NEVER** use this ruleset in production; it allows
  // anyone to overwrite your entire database.

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

Cloud Storage

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with App Engine, this will also make
// files uploaded using App Engine public.
// Warning: This rule makes every file in your Cloud Storage bucket accessible to any user.
// Apply caution before using it in production, since it means anyone
// can overwrite all your files.

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write;
    }
  }
}

Решение: Правила, ограничивающие доступ на чтение и запись.

Создавайте правила, соответствующие вашей иерархии данных. Одним из распространённых решений этой проблемы безопасности является защита на уровне пользователей с помощью Firebase Authentication . Узнайте больше об аутентификации пользователей с помощью правил .

Cloud Firestore

Только владелец контента

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;

    }
  }
}

Смешанный публичный и частный доступ

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

Realtime Database

Только владелец контента

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

Смешанный публичный и частный доступ

{
  // Allow anyone to read data, but only authenticated content owners can
  // make changes to their data

  "rules": {
    "some_path/$uid": {
      ".read": true,
      // or ".read": "auth.uid !== null" for only authenticated users
      ".write": "auth.uid === $uid"
    }
  }
}

Cloud Storage

Только владелец контента

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Смешанный публичный и частный доступ

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

Доступ для любого аутентифицированного пользователя

Иногда Rules проверяют, вошёл ли пользователь в систему, но не ограничивают доступ на основе этой аутентификации. Если одно из ваших правил включает auth != null , подтвердите, что хотите предоставить доступ к данным любому вошедшему в систему пользователю.

Не рекомендуется: любой вошедший в систему пользователь имеет право на чтение и запись всей вашей базы данных.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth.uid != null;
    }
  }
}

Realtime Database

{
  "rules": {
    ".read": "auth.uid !== null",
    ".write": "auth.uid !== null"
  }
}

Cloud Storage

// Only authenticated users can read or write to the bucket
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Решение: Ограничить доступ с помощью условий безопасности.

При проверке аутентификации вы также можете использовать одно из свойств аутентификации, чтобы дополнительно ограничить доступ определённых пользователей к определённым наборам данных. Подробнее о различных свойствах аутентификации …

Cloud Firestore

Ролевой доступ

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

Доступ на основе атрибутов

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "administrator" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}

Смешанный публичный и частный доступ

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}

Realtime Database

Только владелец контента

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid"
      }
    }
  }
}

Доступ с обозначенным путем

{
  "rules": {
    "some_path/$uid": {
      ".write": "auth.uid === $uid",
      // Create a "public" subpath in your dataset
      "public": {
        ".read": true
        // or ".read": "auth.uid !== null"
      },
      // Create a "private" subpath in your dataset
      "private": {
        ".read": "auth.uid === $uid"
      }
    }
  }
}

Смешанный публичный и частный доступ

{
  // Allow anyone to read data, but only authenticated content owners can
  // make changes to their data

  "rules": {
    "some_path/$uid": {
      ".read": true,
      // or ".read": "auth.uid !== null" for only authenticated users
      ".write": "auth.uid === $uid"
    }
  }
}

Cloud Storage

Групповой доступ

// Allow reads if the group ID in your token matches the file metadata `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

Только владелец контента

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Смешанный публичный и частный доступ

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

( Realtime Database ) Неправильно унаследованные правила

Realtime Database Security Rules действуют каскадно: правила в более поверхностных, родительских путях переопределяют правила в более глубоких, дочерних узлах. При создании правила в дочернем узле помните, что оно может предоставлять только дополнительные привилегии. Вы не можете уточнить или отозвать доступ к данным в более глубоких путях базы данных.

Не рекомендуется: уточнение правил в дочерних путях

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

Решение: Напишите общие правила для родительских путей и предоставьте более точные привилегии для дочерних путей. Если ваши потребности в доступе к данным требуют большей детализации, сохраняйте детализированность правил. Подробнее о каскадных Realtime Database Security Rules в разделе «Основной синтаксис Realtime Database Security Rules .

Закрытый доступ

Другой распространённый подход при разработке приложения — сохранение данных в тайне. Обычно это означает, что вы закрываете доступ на чтение и запись для всех пользователей следующим образом:

Cloud Firestore

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Realtime Database

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

Cloud Storage

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

Пакеты Firebase Admin SDK и Cloud Functions по-прежнему смогут получать доступ к вашей базе данных. Используйте эти правила, если вы планируете использовать Cloud Firestore или Realtime Database в качестве серверной платформы совместно с Firebase Admin SDK. Несмотря на безопасность, вам следует проверить, смогут ли клиенты вашего приложения корректно извлекать данные.

Дополнительную информацию о Cloud Firestore Security Rules и о том, как они работают, можно найти в статье Начало работы с Cloud Firestore Security Rules .

Проверьте Cloud Firestore Security Rules

Чтобы проверить поведение приложения и настройки Cloud Firestore Security Rules , используйте эмулятор Firebase . Используйте эмулятор Cloud Firestore для запуска и автоматизации модульных тестов в локальной среде перед внесением каких-либо изменений.

Для быстрой проверки Firebase Security Rules в консоли Firebase используйте симулятор правил Firebase .