Чтобы защитить ресурсы Firebase и данные пользователей, следуйте приведенным ниже рекомендациям. Не все из них могут быть применимы к вашему приложению, но их следует учитывать при разработке.
Как избежать противоправного трафика
Настройте мониторинг и оповещения для бэкенд-служб
Чтобы обнаруживать трафик, связанный со злоупотреблениями, например DoS-атаками, настройте мониторинг и оповещения для Cloud Firestore, Realtime Database, Cloud Storage и Hosting.
Если вы подозреваете, что ваше приложение подверглось атаке, как можно скорее обратитесь в службу поддержки и сообщите о происходящем.
Включить App Check
Чтобы доступ к вашим бэкенд-службам был только у ваших приложений, включите Firebase App Check для всех служб, которые поддерживают эту функцию.
Настройте Cloud Functions так, чтобы он мог обрабатывать обычный трафик
Cloud Functions автоматически масштабируется в соответствии с потребностями приложения, но в случае атаки это может привести к большим расходам. Чтобы этого не произошло, вы можете ограничить количество параллельных экземпляров функции на основе обычного трафика для вашего приложения.
Настройте оповещения о приближении к лимитам
Если в вашем сервисе наблюдаются пики запросов, часто начинают действовать квоты и трафик в ваше приложение автоматически ограничивается.
Регулярно проверяйте панель Использование и оплата.
Настройте оповещения о бюджете для проекта, чтобы получать уведомления, когда использование ресурсов превышает ожидаемые значения.
Если вы используете Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase и Firebase Extensions, настройте пределы расходов, чтобы приостанавливать работу соответствующего сервиса, когда проект достигает заданного для него бюджета.
Предотвращайте DoS-атаки на собственные ресурсы: тестируйте функции локально с помощью эмуляторов
При разработке можно случайно вызвать DoS-атаку на собственный сервис, Cloud Functionsнапример создав бесконечный цикл триггеров и записей. Чтобы избежать ошибок в работе сервисов, используйте для разработки Firebase Local Emulator Suite.
Если вы случайно запустите DoS-атаку на свой проект, отмените развертывание функции, удалив ее из index.js, а затем выполните команду firebase deploy --only functions
Если скорость ответа в реальном времени не так важна, используйте защитное программирование
Если вам не нужно показывать результат функции в реальном времени, вы можете снизить риск злоупотребления трафиком, обрабатывая результаты пакетами: публикуйте результаты в теме Pub/Sub и обрабатывайте их через регулярные интервалы с помощью запланированной функции.
Что такое ключи API
Ключи API для сервисов Firebase не являются секретными
Ключи API для сервисов Firebase только идентифицируют ваш проект и приложение Firebase для этих сервисов. Авторизация выполняется с помощью разрешений IAM Google Cloud, Firebase Security Rules и Firebase App Check.
Все ключи API, предоставленные Firebase, автоматически ограничиваются API, связанными с Firebase. Если ваше приложение настроено в соответствии с рекомендациями на этой странице, то ключи API, ограниченные сервисами Firebase, не нужно считать секретными. Их можно безопасно включать в код или файлы конфигурации.
Как настроить ограничения для ключа API
Если вы используете ключи API для других сервисов Google, убедитесь, что вы применили ограничения ключей API, чтобы ограничить их действие клиентами приложений и используемыми API.
Используйте ключи API, предоставленные Firebase, только для API, связанных с Firebase. Если ваше приложение использует другие API (например, Places API для Карт или Gemini Developer API), используйте отдельный ключ API и ограничьте его применимым API.
Храните ключи сервера FCM в секрете
В отличие от ключей API для сервисов Firebase, FCM серверные ключи (используемые устаревшим HTTP API FCM) являются конфиденциальными и должны храниться в секрете.
Храните ключи сервисных аккаунтов в секрете
В отличие от ключей API для сервисов Firebase, закрытые ключи сервисных аккаунтов (используемые Firebase Admin SDK) являются конфиденциальными и должны храниться в секрете.
Firebase Security Rules
Инициализация правил в рабочем или заблокированном режиме
При настройке Cloud Firestore, Realtime Database и Cloud Storage инициализируйте Firebase Security Rules, чтобы по умолчанию запретить любой доступ, и добавляйте правила, предоставляющие доступ к определенным ресурсам по мере разработки приложения.
Используйте одну из настроек по умолчанию для новых экземпляров Cloud Firestore (рабочий режим) и Realtime Database (режим блокировки). Для Cloud Storage начните с конфигурации правил безопасности, например:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
Правила безопасности – это схема. Добавляйте правила при добавлении документов.
Не пишите правила безопасности после написания приложения, как своего рода задачу подготовки к запуску. Вместо этого пишите правила безопасности по мере написания приложения, рассматривая их как схему базы данных: всякий раз, когда вам нужно использовать новый тип документа или структуру пути, сначала напишите правило безопасности.
Проведите модульное тестирование правил безопасности с помощью Local Emulator Suite и добавьте его в CI.
Чтобы правила безопасности соответствовали разработке приложения, проведите модульное тестирование правил с помощью Firebase Local Emulator Suite и добавьте эти тесты в конвейер непрерывной интеграции. Ознакомьтесь с руководствами по Cloud Firestore и Realtime Database.
Аутентификация
Собственная аутентификация: создание JWT в доверенной среде на стороне сервера
Если у вас уже есть безопасная система входа, будь то собственная разработка или сторонний сервис, вы можете использовать ее для аутентификации в сервисах Firebase. Создайте собственные JWT в доверенной среде, а затем передайте их клиенту, который будет использовать их для аутентификации (iOS+, Android, Web, Unity, C++).
Пример использования специальной аутентификации со сторонним поставщиком приведен в записи блога Аутентификация с помощью Firebase и Okta.
Управляемая аутентификация: поставщики OAuth 2.0 наиболее безопасны
Если вы используете функции управляемой аутентификации Firebase, то наиболее безопасными будут варианты поставщиков OAuth 2.0 / OpenID Connect (Google, Facebook и т. д.). Если это возможно, добавьте поддержку одного или нескольких из этих поставщиков (в зависимости от вашей пользовательской базы).
Аутентификация по адресу электронной почты и паролю: установите строгую квоту для конечной точки входа, чтобы предотвратить атаки методом подбора.
Если вы используете управляемый сервис аутентификации по электронной почте и паролю Firebase, уменьшите квоту по умолчанию для конечных точек identitytoolkit.googleapis.com, чтобы предотвратить атаки методом подбора. Это можно сделать на странице Identity Toolkit API в консоли Google Cloud.
Аутентификация по адресу электронной почты и паролю: включите защиту от перебора адресов электронной почты
Если вы используете управляемый сервис аутентификации по электронной почте и паролю Firebase, включите защиту от перечисления адресов электронной почты. Это предотвратит злоупотребление конечными точками аутентификации вашего проекта для подбора имен аккаунтов злоумышленниками.
Перейдите на версию Google Cloud Identity Platform, чтобы использовать многофакторную аутентификацию
Чтобы повысить безопасность при входе, вы можете добавить поддержку многофакторной аутентификации, перейдя на Google Cloud Identity Platform. После обновления существующий код Firebase Authentication продолжит работать.
Анонимная аутентификация
Используйте анонимную аутентификацию только для предварительной регистрации
Используйте анонимную аутентификацию только для сохранения базового состояния пользователей до того, как они войдут в систему. Анонимная аутентификация не заменяет вход пользователя в аккаунт.
Предложите пользователям перейти на другой способ входа, если они хотят, чтобы их данные были доступны на других устройствах
Анонимные данные аутентификации не сохраняются, если пользователь очищает локальное хранилище или меняет устройство. Если вам нужно сохранять данные после перезапуска приложения на одном устройстве, преобразуйте анонимный аккаунт в постоянный.
Используйте правила безопасности, которые требуют от пользователей перейти на поставщика аутентификации или подтвердить адрес электронной почты.
Любой пользователь может создать анонимный аккаунт в вашем проекте. Поэтому защитите все непубличные данные с помощью правил безопасности, которые требуют определенных способов входа или подтвержденных адресов электронной почты.
Пример:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Cloud Functions: сейфти
Никогда не указывайте конфиденциальную информацию в переменных среды
Часто в приложении Node.js, размещенном на собственном сервере, вы используете переменные среды, содержащие конфиденциальную информацию, например закрытые ключи. Не делайте этого в Cloud Functions. Поскольку Cloud Functions повторно использует среды между вызовами функций, конфиденциальная информация не должна храниться в среде.
Чтобы сохранить ключи Firebase API (которые не являются секретными), просто встройте их в код.
Если вы используете Firebase Admin SDK в Cloud Functions, вам не нужно явно указывать учетные данные сервисного аккаунта, поскольку Admin SDK может автоматически получить их во время инициализации.
Если вы вызываете API Google и Google Cloud, для которых требуются учетные данные сервисного аккаунта, библиотека Google Auth для Node.js может получить эти учетные данные из учетных данных приложения по умолчанию, которые автоматически заполняются в Cloud Functions.
Чтобы закрытые ключи и учетные данные для сторонних сервисов были доступны вашему Cloud Functions, используйте Secret Manager.
Шифрование конфиденциальной информации
Если вы не можете не передавать конфиденциальную информацию в функции, вам необходимо разработать собственное решение для ее шифрования.
Простые функции безопаснее. Если вам нужна более сложная функция, рассмотрите возможность использования Cloud Run.
Старайтесь делать функции как можно более простыми и понятными. Сложность функций часто приводит к трудно обнаруживаемым ошибкам или неожиданному поведению.
Если вам нужна сложная логика или конфигурация среды, используйте Cloud Run вместо Cloud Functions.
Управление средой
Настройте проекты для разработки и тестирования
Настройте отдельные проекты Firebase для разработки, подготовки и выпуска. Не объединяйте код клиента с рабочей версией, пока он не будет протестирован в промежуточном проекте.
Ограничьте доступ команды к рабочим данным
Если вы работаете в большой команде, то можете снизить последствия ошибок и нарушений, ограничив доступ к данным о продукте с помощью предопределенных или специальных ролей IAM.
Если ваша команда использует для разработки Firebase Local Emulator Suite (рекомендуется), то, возможно, вам не нужно предоставлять расширенный доступ к рабочему проекту.
Управление библиотекой
Следите за опечатками в названиях библиотек и новыми сопровождающими
Добавляя библиотеки в проект, обращайте внимание на их названия и разработчиков. Библиотека с похожим названием может содержать вредоносный код.
Не обновляйте библиотеки, не ознакомившись с изменениями
Перед обновлением изучите журналы изменений всех используемых библиотек. Убедитесь, что обновление добавляет ценность, и проверьте, что сопровождающий по-прежнему является стороной, которой вы доверяете.
Установите библиотеки сторожевого таймера как зависимости для разработки или тестирования
Используйте библиотеку, например Snyk, чтобы проверить проект на наличие небезопасных зависимостей.
Настройте мониторинг для Cloud Functions и проверьте его после обновления библиотеки.
Если вы используете Cloud Functions logger SDK, то можете отслеживать необычное поведение и получать уведомления о нем, в том числе о поведении, вызванном обновлениями библиотек.