Google is committed to advancing racial equity for Black communities. See how.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

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

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

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

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

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

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

Облачный Пожарный Магазин

 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 являются единственной защитой, блокирующей доступ злоумышленникам. Определение правил отдельно от логики продукта имеет ряд преимуществ: клиенты не несут ответственности за обеспечение безопасности, ошибочные реализации не скомпрометируют ваши данные, и, самое главное, вы не полагаетесь на сервер-посредник для защиты данных от мира.

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

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

Облачный Пожарный Магазин

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

Правила производства

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

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

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

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

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

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

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

Облачный Пожарный Магазин

 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": "request.auth != null && request.auth.uid == $uid"
        ".write": "request.auth != null && request.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 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 проверяют запрос на соответствие данных из вашей базы данных или метаданных файла, чтобы подтвердить или запретить доступ.

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

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

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

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

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

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

Облачный Пожарный Магазин

Помните, что каждый раз, когда ваши правила включают чтение, как и приведенные ниже правила, вы оплачиваете операцию чтения в 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.

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