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

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

Примечание: Библиотеки клиента сервера обходят все Cloud Firestore Security Rules и вместо этого выполняют аутентификацию через учетные данные Google Application Default Credentials . Если вы используете библиотеки клиента сервера или API REST или RPC, обязательно настройте управление идентификацией и доступом (IAM) для Cloud Firestore .

Если вы получили предупреждение о том, что ваша база данных Cloud Firestore не защищена должным образом, вы можете устранить уязвимости, изменив и протестировав Cloud Firestore Security Rules .

Чтобы просмотреть существующие правила безопасности, перейдите на вкладку «Правила» в консоли Firebase .

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

Поймите Cloud Firestore Security Rules

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && 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 "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /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
    }
  }
}
  

Доступ для непроверенных адресов электронной почты

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

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

Решение: ограничить доступ только проверенными адресами электронной почты.

Проверить электронную почту

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email_verified
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

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

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

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

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

Узнайте больше о Cloud Firestore Security Rules и о том, как они работают, в статье Начало работы с Cloud Firestore Security Rules .

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

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

Чтобы быстро протестировать обновленные Cloud Firestore Security Rules в консоли Firebase, используйте инструмент Rules Playground.

1. Чтобы открыть площадку правил, нажмите «Площадка правил» на вкладке «Правила» .
2. В настройках игровой площадки «Правила» выберите параметры для своего теста, в том числе:
   • Тестирование чтения или записи
   • Определенное местоположение в вашей базе данных, как путь
   • Тип аутентификации — неаутентифицированный, аутентифицированный анонимный пользователь или определенный идентификатор пользователя
   • Данные, специфичные для документа, на которые ссылаются ваши правила (например, если ваши правила требуют наличия определенного поля перед разрешением записи)
3. Нажмите «Выполнить» и посмотрите результаты на баннере над окном правил.