Используйте это руководство, чтобы понять распространенные уязвимости в конфигурациях Firebase Security Rules , просмотреть и лучше защитить собственные правила, а также протестировать изменения перед их развертыванием.
Если вы получили предупреждение о том, что ваши данные не защищены должным образом, просмотрите эти распространенные ошибки и обновите все уязвимые правила.
Доступ к Firebase Security Rules
Чтобы просмотреть существующие Rules , используйте Firebase CLI или консоль Firebase . Убедитесь, что вы редактируете правила, используя один и тот же метод, последовательно, чтобы избежать ошибочной перезаписи обновлений. Если вы не уверены, отражают ли ваши локально определенные правила самые последние обновления, консоль Firebase всегда показывает самую последнюю развернутую версию ваших Firebase Security Rules .
Чтобы получить доступ к правилам из консоли Firebase , выберите свой проект, затем перейдите в Realtime Database , Cloud Firestore или Storage . Нажмите Rules , как только вы окажетесь в нужной базе данных или хранилище.
Чтобы получить доступ к правилам из Firebase CLI, перейдите к файлу правил, указанному в файле firebase.json .
Понимание Firebase Security Rules
Firebase Security Rules защищают ваши данные от злоумышленников. Когда вы создаете экземпляр базы данных или контейнер Cloud Storage в консоли Firebase , вы можете либо запретить доступ всем пользователям ( режим Locked ), либо предоставить доступ всем пользователям ( режим Test ). Хотя вам может понадобиться более открытая конфигурация во время разработки, убедитесь, что вы нашли время, чтобы правильно настроить правила и защитить свои данные перед развертыванием приложения.
При разработке приложения и тестировании различных конфигураций правил используйте один из локальных эмуляторов Firebase для запуска приложения в локальной среде разработки.
Распространенные сценарии с небезопасными правилами
Rules вы могли установить по умолчанию или изначально при разработке приложения, следует пересмотреть и обновить перед развертыванием приложения. Убедитесь, что вы надежно защищаете данные пользователей, избегая следующих распространенных ошибок.
Открытый доступ
При настройке проекта Firebase вы могли задать правила, разрешающие открытый доступ во время разработки. Вы можете подумать, что вы единственный человек, использующий ваше приложение, но если вы его развернули, оно доступно в Интернете. Если вы не аутентифицируете пользователей и не настраиваете правила безопасности, то любой, кто угадает ваш идентификатор проекта, может украсть, изменить или удалить данные.
Не рекомендуется: доступ на чтение и запись для всех пользователей. Cloud Firestore// Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if true; } } } Realtime Database{ // Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. "rules": { ".read": true, ".write": true } } Cloud Storage// Anyone can read or write to the bucket, even non-users of your app. // Because it is shared with App Engine, this will also make // files uploaded using App Engine public. // Warning: This rule makes every file in your Cloud Storage bucket accessible to any user. // Apply caution before using it in production, since it means anyone // can overwrite all your files. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write; } } } |
Решение: Правила, ограничивающие доступ на чтение и запись. Создавайте правила, которые имеют смысл для вашей иерархии данных. Одним из распространенных решений этой небезопасности является безопасность на основе пользователя с Firebase Authentication . Узнайте больше об аутентификации пользователей с помощью правил . Cloud FirestoreRealtime DatabaseCloud Storage |
Доступ для любого аутентифицированного пользователя
Иногда Rules проверяют, вошел ли пользователь в систему, но не ограничивают доступ на основе этой аутентификации. Если одно из ваших правил включает auth != null
, подтвердите, что вы хотите, чтобы любой вошедший в систему пользователь имел доступ к данным.
Не рекомендуется: любой вошедший в систему пользователь имеет доступ на чтение и запись ко всей вашей базе данных. Cloud Firestoreservice cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth.uid != null; } } } Realtime Database{ "rules": { ".read": "auth.uid !== null", ".write": "auth.uid !== null" } } Cloud Storage// Only authenticated users can read or write to the bucket service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if request.auth != null; } } } |
Решение: ограничить доступ с помощью условий безопасности. При проверке аутентификации вы также можете захотеть использовать одно из свойств аутентификации, чтобы еще больше ограничить доступ определенным пользователям к определенным наборам данных. Узнайте больше о различных свойствах аутентификации . Cloud FirestoreRealtime DatabaseCloud Storage |
( Realtime Database ) Неправильно унаследованные правила
Realtime Database Security Rules каскадируются, при этом правила в более мелких родительских путях переопределяют правила в более глубоких дочерних узлах. Когда вы пишете правило в дочернем узле, помните, что оно может только предоставлять дополнительные привилегии. Вы не можете уточнить или отменить доступ к данным в более глубоком пути в вашей базе данных.
Не рекомендуется: уточнение правил в дочерних путях { "rules": { "foo": { // allows read to /foo/* ".read": "data.child('baz').val() === true", "bar": { /* ignored, since read was allowed already */ ".read": false } } } } |
Решение: Напишите правила в родительских путях, которые являются общими, и предоставьте более конкретные привилегии в дочерних путях. Если ваши потребности в доступе к данным требуют большей детализации, сохраняйте свои правила детализированными. Узнайте больше о каскадировании Realtime Database Security Rules в разделе Основной синтаксис Realtime Database Security Rules . |
Закрытый доступ
Пока вы разрабатываете свое приложение, еще один распространенный подход — держать свои данные заблокированными. Обычно это означает, что вы закрыли доступ на чтение и запись для всех пользователей следующим образом:
Cloud Firestore
// Deny read/write access to all users under any conditions service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if false; } } }
Realtime Database
{ "rules": { ".read": false, ".write": false } }
Cloud Storage
// Access to files through Cloud Storage is completely disallowed. // Files may still be accessible through App Engine or Google Cloud Storage APIs. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if false; } } }
Firebase Admin SDK и Cloud Functions по-прежнему могут получать доступ к вашей базе данных. Используйте эти правила, если вы собираетесь использовать Cloud Firestore или Realtime Database в качестве серверного бэкэнда в сочетании с Firebase Admin SDK. Хотя это безопасно, вам следует проверить, что клиенты вашего приложения могут правильно извлекать данные.
Узнайте больше о Cloud Firestore Security Rules и о том, как они работают, в статье Начало работы с Cloud Firestore Security Rules .
Проверьте свои Cloud Firestore Security Rules
Чтобы проверить поведение вашего приложения и проверить конфигурации Cloud Firestore Security Rules , используйте эмулятор Firebase . Используйте эмулятор Cloud Firestore для запуска и автоматизации модульных тестов в локальной среде перед развертыванием любых изменений.
Для быстрой проверки Firebase Security Rules в консоли Firebase используйте симулятор правил Firebase .