Connect with us

Разработка

Firebase Firestore: основные правила безопасности

Опубликовано

/

     
     

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

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

В этой статье мы рассмотрим основные правила обеспечения безопасности базы данных Firestore.

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

Управление доступом на основе аутентификации

Доступ только аутентифицированных пользователей

Чтобы разрешить доступ только аутентифицированным пользователям, в правилах безопасности Firestore вы можете использовать следующее:

Это правило использует переменную request.auth, чтобы проверить, аутентифицирован ли пользователь, делающий запрос. Если пользователь аутентифицирован, он может читать/писать документ. Если пользователь не аутентифицирован, ему будет отказано в доступе.

Проверка доступа по электронной почте

Управление доступом по владельцу

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

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

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

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

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

В данном случае каждый документ в коллекции collectionName имеет поле userId, которое содержит UID владельца документа.

Правило проверяет, совпадает ли request.auth.uid с полем userId документа, в который производится запись. Если UID совпадают, пользователю разрешается запись в документ. Если они не совпадают, доступ к записи запрещен.

Контроль доступа на уровне документов

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

Чтобы гарантировать, что только члены рабочего пространства могут читать его информацию, вы можете определить правило управления доступом на уровне документа следующим образом:

В этом правиле мы используем функцию exists(), чтобы проверить, существует ли UID пользователя (который доступен в request.auth.uid) как идентификатор документа в подколлекции members документа рабочей области.

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

Управление доступом на основе ролей

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

Пример 1. Чтобы разрешить пользователю писать документ, только если он имеет тип роли «редактор», вы можете использовать следующее правило безопасности Firestore:

Правило проверяет поле request.auth.token.roleType, чтобы убедиться, что пользователь имеет правильный тип роли, прежде чем разрешить ему чтение/запись документа.

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

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

Правила валидации на уровне полей

Проверка принадлежности значения к списку

Рассмотрим простой пример. Предположим, у вас есть коллекция рабочих пространств в базе данных Firestore с подколлекцией members. Каждый член имеет поле role_type, которое может быть admin, member, HR или guest.

Теперь, допустим, вы хотите разрешить доступ на запись только тем пользователям, которые имеют роль admin, member или hr. Пользователи вне этих ролей не смогут обновить подколлекцию members документа рабочей области. Для этого можно использовать следующее правило безопасности Firestore:

Правило разрешает доступ на запись к подколлекции members только в том случае, если пользователь, делающий запрос, аутентифицирован (request.auth != null) и если поле role_type запрашиваемого документа является либо admin, либо member, либо hr.

Требование всех полей для записи

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

Метод request.resource.data.keys().hasAll() проверяет, содержит ли объект запроса все необходимые поля. Если да, то правило разрешает доступ к созданию. Если нет, правило запрещает доступ.

Ограничение обновлений для определенных полей

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

Ограничение доступа к созданию с обязательными и необязательными полями

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

 Разрешение обновления только определенных полей

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

Контроль доступа на основе времени

Пример 1. Предположим, у вас есть мобильное приложение, позволяющее пользователям бронировать встречи с врачом. Вы хотите обеспечить, чтобы запись на прием к врачу осуществлялась только в рабочее время (т.е. с 9 утра до 5 вечера в будние дни).

Пример 2. Разрешить запись в документ только один раз в день:

Это правило сравнивает дату запроса с датой из поля lastUpdated документа. Оно разрешает доступ к записи, только если даты не равны и пользователь аутентифицирован.

Проверка типа данных

Правило проверки типа данных поля — это правило безопасности, которое проверяет, имеют ли данные в определенном поле документа ожидаемый тип данных.

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

Вот список всех различных типов данных, которые можно проверить:

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

Валидация типа данных необязательного поля

Для примера рассмотрим документ пользователя, в котором есть необязательные поля для номера телефона и адреса. Правило будет проверять, является ли поле номера телефона, если оно присутствует, типом number, а поле адреса, если оно присутствует, типом string.

Сложность пароля

В этом примере мы требуем, чтобы пароли:

  • состояли не менее чем из 8 символов
  • содержали как минимум одну букву и одну цифру

Проверка электронной почты

 Заключение

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

Спасибо, что прочитали, и удачного кодинга! 👋

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: