Основные правила безопасности

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

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

Чтобы получить доступ к своим правилам и обновить их, выполните действия, описанные в разделе «Управление и развертывание Firebase Security Rules .

Правила по умолчанию: заблокированный режим

Когда вы создаете экземпляр базы данных или хранилища в консоли Firebase , вы выбираете, ограничивают ли ваши Firebase Security Rules доступ к вашим данным ( режим блокировки ) или разрешают кому-либо доступ ( тестовый режим ). В Cloud Firestore и Realtime Database правила по умолчанию для режима блокировки запрещают доступ всем пользователям. В Cloud Storage только прошедшие проверку подлинности пользователи могут получить доступ к сегментам хранилища.

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

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

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

Правила среды разработки

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

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

Все авторизованные пользователи

Хотя мы не рекомендуем оставлять ваши данные доступными для любого пользователя, вошедшего в систему, может быть полезно настроить доступ для любого пользователя, прошедшего проверку подлинности, во время разработки приложения.

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

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

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

Готовые к производству правила

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

Рассмотрите возможность написания правил при структурировании данных, поскольку способ настройки правил влияет на то, как вы ограничиваете доступ к данным по различным путям.

Доступ только для владельцев контента

Эти правила ограничивают доступ только проверенному владельцу контента. Данные доступны для чтения и записи только одному пользователю, а путь к данным содержит идентификатор пользователя.

Когда это правило работает: Это правило хорошо работает, если данные разделены по пользователям — если единственным пользователем, которому нужен доступ к данным, является тот же пользователь, который создал данные.

Когда это правило не работает: Этот набор правил не работает, когда нескольким пользователям необходимо записать или прочитать одни и те же данные — пользователи перезапишут данные или не смогут получить доступ к созданным ими данным.

Чтобы настроить это правило: Создайте правило, которое подтверждает, что пользователь, запрашивающий доступ для чтения или записи данных, является пользователем, которому принадлежат эти данные.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{documents=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

{
  "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"
      }
    }
  }
}

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

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

Это правило позволяет любому читать набор данных, но ограничивает возможность создавать или изменять данные по заданному пути только авторизованному владельцу контента.

Когда это правило работает: это правило хорошо работает для приложений, которым требуются общедоступные элементы, но которым необходимо ограничить доступ к редактированию владельцам этих элементов. Например, чат-приложение или блог.

Когда это правило не работает: как и правило только для владельца контента, этот набор правил не работает, когда несколько пользователей должны редактировать одни и те же данные. В конечном итоге пользователи перезапишут данные друг друга.

Чтобы настроить это правило: Создайте правило, которое разрешает доступ на чтение для всех пользователей (или всех прошедших проверку подлинности пользователей) и подтверждает, что пользователь, записывающий данные, является владельцем.

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;
    }
  }
}

{
// 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"
      }
    }
  }
}

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

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

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

Когда это правило работает: если вы назначаете роль пользователям, это правило позволяет легко ограничить доступ на основе ролей или определенных групп пользователей. Например, если вы храните оценки, вы можете назначить разные уровни доступа группе «Учащиеся» (только чтение их содержимого), группе «Учителя» (чтение и запись по своему предмету) и группе «Директора» (чтение весь контент).

Когда это правило не работает: в Realtime Database и Cloud Storage ваши правила не могут использовать метод get() , который могут включать правила Cloud Firestore . Следовательно, вам необходимо структурировать свою базу данных или метаданные файла так, чтобы они отражали атрибуты, которые вы используете в своих правилах.

Чтобы настроить это правило: в Cloud Firestore включите в документы пользователей поле, которое вы можете прочитать, затем структурируйте свое правило для чтения этого поля и условно предоставьте доступ. В Realtime Database создайте путь к данным, который определяет пользователей вашего приложения и предоставляет им роль в дочернем узле.

Вы также можете настроить собственные утверждения в Authentication , а затем получить эту информацию из переменной auth.token в любых Firebase Security Rules .

Определяемые данными атрибуты и роли

Эти правила работают только в Cloud Firestore и Realtime Database .

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    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"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

Атрибуты и роли настраиваемых утверждений

Чтобы реализовать эти правила, настройте собственные утверждения в Firebase Authentication , а затем используйте утверждения в своих правилах.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to leverage
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

service firebase.storage {
  // Allow reads if the group ID in your token matches the file metadata's `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;
  }
}

Атрибуты аренды

Чтобы реализовать эти правила, настройте мультиарендность в Google Cloud Identity Platform (GCIP), а затем используйте арендатора в своих правилах. Следующие примеры разрешают запись от пользователя в определенном клиенте, например tenant2-m6tyz

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}