Воспользуйтесь этим руководством, чтобы понять распространенные уязвимости в конфигурациях Firebase Security Rules , проверить и улучшить защиту собственных правил, а также протестировать изменения перед их развертыванием.
Если вы получили предупреждение о том, что ваши данные недостаточно защищены, просмотрите эти распространенные ошибки и обновите все уязвимые правила.
AI prompt for AI assistance
Для использования ИИ-помощи скопируйте приведенную ниже подсказку в свой агент программирования с поддержкой ИИ (например, Gemini в Android Studio, Antigravity , Claude Code, Codex и Cursor). Вы можете настроить подсказку и взаимодействовать с агентом. Подробную информацию об установке см. в разделе «Навыки агентов Firebase» .
Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's data.
Получите доступ к своим Firebase Security Rules
To view your existing Security Rules , use either the Firebase CLI or the Firebase console. Make sure you edit your rules using the same method, consistently, to avoid mistakenly overwriting updates. If you're not sure whether your locally defined rules reflect the most recent updates, the Firebase console always shows the most recently deployed version of your Firebase Security Rules .
Чтобы получить доступ к правилам из консоли Firebase , выберите свой проект, затем перейдите в Realtime Database , Cloud Firestore или «Хранилище» . После того, как вы окажетесь в нужной базе данных или хранилище, нажмите «Правила» .
Чтобы получить доступ к своим правилам из Firebase CLI, перейдите к файлу правил, указанному в вашем файле firebase.json .
Разберитесь Firebase Security Rules
Firebase Security Rules protect your data from malicious users. When you create a database instance or Cloud Storage bucket in the Firebase console, you can choose to either deny access to all users ( Locked mode ) or grant access to all users ( Test mode ). While you might want a more open configuration during development, make sure you take the time to properly configure your rules and secure your data before deploying your app.
В процессе разработки приложения и тестирования различных конфигураций правил используйте один из локальных эмуляторов Firebase для запуска приложения в локальной среде разработки.
Типичные сценарии с небезопасными правилами
Перед развертыванием приложения необходимо проверить и обновить Security 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 |
Доступ предоставляется любому авторизованному пользователю.
Иногда Security 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; } } }