Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

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

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

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

Чтобы получить доступ и обновить правила, выполните действия , описанные в управление и развертывание правил безопасности Firebase .

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

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

Cloud Firestore

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

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

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

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

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

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

Cloud Firestore

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

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

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

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

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

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

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

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

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

Cloud Firestore

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

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

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

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

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

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

Cloud Firestore

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 create: if request.auth.uid == request.resource.data.author_uid;
      allow update, 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 проверяют запрос на соответствие данным из вашей базы данных или метаданным файла, чтобы подтвердить или запретить доступ.

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

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

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

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

Атрибуты и роли, определенные данными

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

Cloud Firestore

Помните, что каждый раз, когда ваши правила включают чтение, как, например, правила ниже, вам выставляется счет за операцию чтения в Cloud Firestore.

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 проверке подлинности , а затем использовать требование в правилах.

Cloud Firestore

Помните, что каждый раз, когда ваши правила включают чтение, как, например, правила ниже, вам выставляется счет за операцию чтения в Cloud Firestore.

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