FixVibe

// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true пояснено: що це робить і як виправити

<code>allow read, write: if true;</code> — найпоширеніше неправильне налаштування Firebase у продакшені. Це значення за замовчуванням у тестовому режимі, яке Консоль Firebase пропонує під час створення нової бази даних, правило, яке ШІ-інструменти кодування регенерують із документації, і правило, яке відкриває всю вашу базу даних Firestore будь-кому в інтернеті. Ця стаття пояснює синтаксис точно, показує, що бачить зловмисник, коли це правило активне, та надає вам чотири дедалі суворіші заміни, що підходять для різних випадків використання.

Синтаксис, рядок за рядком

Повний документ правил Firestore у тестовому режимі — шість рядків:

firebase
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.

Чистий ефект: будь-який клієнт із ID проєкту Firebase і правильним SDK може читати або писати будь-який документ у будь-якій колекції. Автентифікація не потрібна. Обмеження швидкості не нав'язуються.

Чому Firebase постачає це за замовчуванням

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

Структурна проблема: ШІ-інструменти кодування тренуються на документації, туторіалах та відповідях на Stack Overflow, які показують правила тестового режиму. Коли ви запитуєте Cursor чи Claude Code "як налаштувати Firebase", відповідь часто включає точний блок allow read, write: if true, як якщо б це було продакшен-правило. ШІ не знає — і його не підказують знати — що це правило не безпечне для продакшену.

Що бачить зловмисник

Конкретно, зловмисник, який знає ID вашого проєкту Firebase (витягується з бандла будь-якого розгорнутого застосунку за 30 секунд) та запускає наступне, може перелічити кожен документ у кожній колекції:

Одного неавтентифікованого curl-запиту достатньо для перерахування кожної колекції. Дивіться виділений блок нижче.

bash
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 або будь-який провайдер, який видає Firebase ID токен):

Варіант 1: Документи, що належать користувачам

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

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

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

Коли документи живуть у плоских колекціях (не вкладених під ID користувача), зберігайте поле 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; }

firebase
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 на кожному документі та перевіряйте його проти користувацького claim користувача. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Потребує встановлення користувацького claim під час реєстрації через Firebase Admin SDK.

firebase
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; }. Користувацький claim admin встановлюється лише на адміністраторських акаунтах.

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

Швидкий запит аудиту

Перед виправленням перевірте, чи if true справді активне. Відкрийте Консоль Firebase → Firestore → Rules та шукайте if true. Якщо ви знайдете його будь-де поза коментарем, у вас є знахідка відкритого правила. Симулятор правил у тому ж UI дозволяє відтворити запит зловмисника локально — вставте анонімне GET /users/somebody і підтвердьте, що симулятор повертає Allowed.

Зовнішнє підтвердження: запустіть сканування FixVibe проти вашого продакшен-URL. Перевірка baas.firebase-rules зондує ваші правила Firestore, Realtime Database та Storage та звітує про ту саму знахідку, яку виявив би зловмисник — незалежно від того, що показує Консоль Firebase.

Поширені запитання

У чому різниця між <code>if true</code> та <code>if request.auth != null</code>?

if true дозволяє анонімний доступ — будь-кому в інтернеті. if request.auth != null вимагає будь-якого залогіненого користувача, що краще, але все ще неправильно: будь-який користувач вашого застосунку може читати дані кожного іншого користувача. Продакшен-правила мають обмежувати до конкретного користувача або організації через request.auth.uid == resource.data.owner_uid або подібне.

Чи Firebase коли-небудь автоматично закінчує термін дії правил <code>if true</code>?

Старіші проєкти (до 2023) мали 30-денний таймер, який перетворював правила if true на if false. Поточні проєкти — ні; правило зберігається безстроково, доки не буде вручну замінене. Якщо ви створили свій проєкт до 2023 і ваші правила виглядають добре, перевірте двічі: таймер міг уже перевести їх на if false, що блокує ваш власний застосунок.

Чи можу я використовувати перевірку часової мітки в майбутньому як страхувальну сітку?

Ні — умова часової мітки не є контролем безпеки. Вона закінчує термін дії відкритого правила в майбутню дату, що означає, що до цієї дати зловмисники мають повний доступ. І ви забудете дату. Замініть if true на правило з auth-обмеженням, а не на обмежене за часом.

Що, якщо мій застосунок справді публічно-читаний (блог, каталог продуктів)?

Тоді явно напишіть allow read: if true; allow write: if false; лише на публічній колекції — а не на кожній колекції у вашій базі даних. Використовуйте окреме match-речення для кожної колекції та ніколи не використовуйте рекурсивний шаблон {document=**} на правилах із записом.

Наступні кроки

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

// скануйте вашу baas-поверхню

Знайдіть відкриту таблицю раніше, ніж це зробить хтось інший.

Введіть продакшен-URL. FixVibe перелічить постачальників BaaS, з якими взаємодіє ваш застосунок, зніме відбитки з їхніх публічних кінцевих точок і повідомить, що неавторизований клієнт може прочитати або записати. Безкоштовно, без встановлення, без картки.

  • Безкоштовний тариф — 3 сканування на місяць, без картки під час реєстрації.
  • Пасивне зняття відбитків BaaS — не потрібна перевірка володіння доменом.
  • Supabase, Firebase, Clerk, Auth0, Appwrite та інші.
  • Підказки виправлення від ШІ для кожної знахідки — вставте назад у Cursor / Claude Code.
Запустити безкоштовне сканування BaaS →

реєстрація не потрібна

Firebase allow read, write: if true пояснено: що це робить і як виправити — Docs · FixVibe