Объяснение 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, как если бы это было производственное правило. ИИ не знает — и его не подсказывают знать — что это правило небезопасно для продакшена.

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

Concretely, an attacker who knows your Firebase project ID (it ships in every deployed app's configuration) can list every collection and read every document with plain, unauthenticated requests to Firebase's public REST API.

Once the collections are listed, every document in them can be read. Nothing slows this down, because if true rules accept anonymous traffic.

По пути записи: один 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.

External confirmation: run a FixVibe scan against your production URL. FixVibe checks your Firestore, Realtime Database, and Storage rules from the outside and reports what an attacker would find — independent of what the Firebase Console shows.

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

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

Run a FixVibe scan against your production URL — it confirms whether if true is currently exploitable from the public internet. For how the scanner covers Realtime Database and Storage as well, see Firebase rules scanner. For the equivalent class of misconfiguration on Supabase, read Supabase RLS scanner.