Firebase: разделять идентификацию, права, хранение и сообщения

Кратко

Firebase объединяет сервисы с разными SDK, правами и тарифами. Идентификация пользователя не разрешает доступ ко всем данным. Безопасность и стоимость оценивают по каждому сервису.

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

Firebase объединяет сервисы с разными SDK, правами и тарифами. Идентификация пользователя не разрешает доступ ко всем данным. Безопасность и стоимость оценивают по каждому сервису.

Аутентификация и авторизация

Firebase Authentication управляет входом; права определяются отдельно. Веб- и мобильные клиенты Cloud Firestore используют Security Rules. Серверные библиотеки обходят эти правила и используют IAM: один контроль не охватывает оба пути. Документированная веб-MFA требует Firebase Authentication with Identity Platform.

Данные и файлы

Cloud Firestore и Realtime Database — разные сервисы баз данных; Cloud Storage хранит объекты, например файлы. Единого правила безопасности у них нет. Текущая FAQ требует Blaze для Cloud Storage for Firebase, включая существующие buckets; бесплатные объёмы использования могут сохраняться. Проверять квоты и оплату до обещаний бесплатности.

Уведомления FCM

FCM HTTP v1 использует серверную авторизацию, включая краткоживущие токены OAuth 2.0. Отправка должна идти из доверенной среды, без административных учётных данных в клиенте. Токен регистрации устройства задаёт адресата; это не пользовательский ID token и не бизнес-разрешение.

Сеансы и эксплуатация

Различать ID token, refresh token и отзыв. Криптографическая корректность не доказывает сохранение прав. Определить полезные журналы, хранение, оповещения о расходах и проверки ресурсов. Firebase автоматически не обеспечивает соответствие GDPR.

Источники

Редакционная проверка: 1 ноября 2026 года.

Переносите решения по идентификации в обработчики событий.

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

  • Протестируйте одно и то же поле под разными ролями и владельцами.
  • Запретить доступ к объектам перед вычислением вложенных полей.
  • Воспроизведение после смены ролей или отзыва сессии.

Первичный источник: OWASP — GraphQL Cheat Sheet. Связанный метод: прочитать практическое руководство.

Пагинация API и целостный экспорт

Изменяющийся набор может приводить к пропускам и повторениям.

  • Запишите фильтры, сортировку и ключ для одинаковых значений. Уточните, даёт ли API снимок или изменяемую коллекцию. Проверьте создание и удаление во время чтения: наличие курсора не гарантирует неизменность данных.
  • В AIP-158 чтение завершает пустой next_page_token, а не короткая или пустая страница результатов. Вымышленные страницы [A,B] и [B,C] содержат четыре строки, но три уникальных идентификатора. Выявляйте повтор курсора без продвижения и соблюдайте контракт используемого API.
  • Надёжно сохраните пакет до подтверждения продолжения. Повторите прерванный пакет по стабильным идентификаторам и проверяйте права при каждом запросе: курсор не даёт доступа. Если снимок истёк, начните заново или явно сверяйте; не объединяйте разные состояния молча.

Воспроизводимый приёмочный случай

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

Посмотреть данные случая
{
    "page_1_ids": [
        "A",
        "B"
    ],
    "page_2_ids": [
        "B",
        "C"
    ],
    "next_cursor": "c2",
    "empty_page_has_next_cursor": true
}

Ожидаемое решение

B повторяется. Проверьте идентификаторы и продолжайте по курсору даже после пустой страницы.

Процедура проверки

  1. Определите фильтры, устойчивый порядок и идентичность.
  2. Проверьте дубль и пустую страницу с курсором.
  3. Сохраните идентификаторы и настоящее условие завершения. Сопоставьте полученные объекты и уникальные идентификаторы; отмечайте повтор курсора, не считая пустую страницу с продолжением концом сбора.

Google AIP-158 — Pagination

Доказывает ли ожидаемое число строк полноту выгрузки?

Нет. Пропущенный и повторный идентификаторы могут взаимно компенсироваться в количестве. Сверьте идентификаторы, область и отсечку и запишите нерешённые различия.

Первичный источник: Google AIP-158 — Pagination. Связанный метод: прочитать практическое руководство.

Passkey: подготовить смену домена и RP ID

Разделить учётную запись, веб-источник и RP ID, чтобы не переназначать данные входа скрытно.

  • Запишите старые и новые источники, RP ID и связанные записи. Одинаковое имя записи не делает passkey действительным для другого RP ID. Проверьте допустимые сочетания WebAuthn и доступные пути входа на переходе.
  • В разрешённой тестовой среде проверьте challenge, источник, RP ID и связь с записью подходящей библиотекой. Испытайте неожиданный источник и повтор challenge. Смена RP ID требует новой аутентифицированной регистрации: копирование строки не переносит ключ.
  • Проверьте пользователя только со старым credential, восстановление и открытые сессии. Задайте открытие и закрытие путей с проверенным возвратом. Регистрация на новом домене не доказывает отзыв всех старых сессий.

Воспроизводимый приёмочный случай

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

Посмотреть данные случая
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

Ожидаемое решение

Вымышленный пример: запись та же, но old.example меняется на new.example с другим RP ID. Старый credential нельзя скрытно перепривязать; новая регистрация проходит предусмотренный аутентифицированный путь.

W3C — Web Authentication Level 2

Первичный источник: W3C — Web Authentication Level 2. Связанный метод: прочитать практическое руководство.

Идентификация: факторы, сеансы и восстановление

Firebase: короткий токен не завершает весь сеанс

Документация задаёт срок ID token в один час; refresh token позволяет получать новые токены. Отзыв refresh token и обнаружение отзыва ID token — разные проверки.

  • Связывать отзыв с нужной учётной записью.
  • Использовать документированную проверку отзыва SDK, например checkRevoked.
  • Проверять старый токен на каждом защищённом backend и контролировать права.

Подробнее о контроле идентификации →

Источники проверены · NIST · Authenticator Event Management NIST · Session Management Firebase · Manage User Sessions