Объяснение Firebase allow read, write: if true: что это делает и как это исправить

Синтаксис, строка за строкой

Полный документ правил тестового режима Firestore состоит из шести строк:

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

Декодировано:

• rules_version = '2'; выбирает движок правил v2 (текущий). Старые правила v1 устарели.
• service cloud.firestore ограничивает блок Firestore. Realtime Database использует другой синтаксис на основе JSON; Cloud Storage использует service firebase.storage.
• match /databases/{database}/documents связывает специальную базу данных (default) (у большинства проектов есть только одна).
• match /{document=**} — это рекурсивный подстановочный знак. ** соответствует любому пути любой глубины. В сочетании с {document} это захватывает каждый документ в каждой коллекции — единственное предложение match, управляющее всей базой данных.
• allow read, write: if true; — это тело правила. И read, и write разрешены; условие if true, что ж, всегда истинно. read охватывает операции get и list; write охватывает create, update и delete.

Чистый эффект: любой клиент с идентификатором проекта Firebase и правильным SDK может читать или писать любой документ в любой коллекции. Аутентификация не требуется. Ограничения скорости не применяются.

Почему Firebase предоставляет это по умолчанию

Firebase хочет, чтобы вы программировали в первые 30 секунд после создания проекта. Альтернатива — заставить вас написать правильное правило перед тем, как любое чтение или запись заработает — заблокировала бы онбординг. Поэтому Консоль предлагает два варианта при создании базы данных: Производственный режим (отклонять всё, вы пишете правила) или Тестовый режим (разрешать всё на 30 дней). Большинство разработчиков нажимают тестовый режим, а затем забывают возвратиться. У старых проектов был 30-дневный таймер; текущие проекты имеют неопределённое правило if true без автоматического истечения.

Структурная проблема: ИИ-инструменты кодирования обучаются на документации, учебниках и ответах Stack Overflow, которые показывают правила тестового режима. Когда вы спрашиваете Cursor или Claude Code «как мне настроить Firebase», ответ часто включает точный блок allow read, write: if true, как если бы это было производственное правило. ИИ не знает — и его не подсказывают знать — что это правило небезопасно для продакшена.

Что видит злоумышленник

Конкретно, злоумышленник, который знает идентификатор вашего проекта Firebase (извлекаемый из бандла любого развёрнутого приложения за 30 секунд) и запускает следующее, может перечислить каждый документ в каждой коллекции:

Одного неаутентифицированного curl-запроса достаточно, чтобы перечислить каждую коллекцию. См. выделенный блок ниже.

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

Ответ — это полный список коллекций верхнего уровня. Для каждой коллекции второй запрос возвращает документы. На этом пути нет ограничений скорости, потому что правила if true принимают анонимный трафик. Мы видели базы данных Firebase с миллионами документов, перечисленные менее чем за час.

По пути записи: один POST с {fields} создаёт новый документ. Злоумышленники могут засорять ваши коллекции мусором, портить пользовательские страницы, которые читают из Firestore, или использовать вашу базу данных как бесплатный брокер сообщений — ваш счёт за использование резко возрастает, вы расследуете, счёт объясняет проблему.

Четыре замены, безопасные для продакшена

Выберите замену, которая соответствует модели данных вашего приложения. Все четыре предполагают, что у вас есть аутентификация пользователя (Firebase Auth или любой провайдер, который выдаёт токен ID Firebase):

Вариант 1: Документы, принадлежащие пользователю

Наиболее распространённый шаблон SaaS. Документы живут под /users/{userId}/..., и только владелец может к ним прикасаться. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Вариант 2: Поле владельца в каждом документе

Когда документы живут в плоских коллекциях (не вложены под идентификатором пользователя), храните поле owner_uid и проверяйте его. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Вариант 3: Многоарендная изоляция организации

Для B2B SaaS с данными в рамках организации. Храните поле org_id в каждом документе и проверяйте его против пользовательского пользовательского утверждения. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Требует установки пользовательского утверждения во время регистрации через Firebase Admin SDK.

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Вариант 4: Публичный контент только для чтения

Для маркетингового контента, публичных профилей, каталогов продуктов — всего, что действительно является публичным для чтения, но только админ для записи. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Пользовательское утверждение admin устанавливается только для админских аккаунтов.

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Быстрый аудит-запрос

Перед исправлением проверьте, действительно ли if true активен. Откройте Firebase Console → Firestore → Rules и поищите if true. Если вы найдёте его где-либо вне комментария, у вас есть находка открытого правила. Симулятор правил в том же интерфейсе позволяет воспроизвести запрос злоумышленника локально — вставьте анонимный GET /users/somebody и подтвердите, что симулятор возвращает Allowed.

Внешнее подтверждение: запустите сканирование FixVibe против вашего производственного URL. Проверка baas.firebase-rules зондирует ваши правила Firestore, Realtime Database и Storage и сообщает о той же находке, которую обнаружил бы злоумышленник — независимо от того, что показывает Firebase Console.

Часто задаваемые вопросы

Следующие шаги

Запустите сканирование FixVibe против вашего производственного URL — проверка baas.firebase-rules подтверждает, является ли if true в настоящее время эксплуатируемой из публичного интернета. О механике сканера и параллельных обнаружениях для Realtime Database и Storage см. Сканер правил Firebase. Об эквивалентном классе неправильной настройки на Supabase прочитайте Сканер Supabase RLS.