FixVibe

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

Firebase allow read, write: if true обяснено: какво прави и как да го поправите

<code>allow read, write: if true;</code> е най-разпространената неправилна конфигурация на Firebase в продукция. Това е стойността по подразбиране в test-mode, която Firebase Console предлага, когато създадете нова база данни, правилото, което AI инструментите за кодиране регенерират от документацията, и правилото, което отваря цялата ви Firestore база данни за всеки в интернет. Тази статия обяснява синтаксиса прецизно, показва какво вижда нападател, когато това правило е активно, и ви дава четири прогресивно по-строги замени, които отговарят на различни случаи на употреба.

Синтаксисът, ред по ред

Пълен документ с правила за Firestore test-mode е шест реда:

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

Декодирано:

  • rules_version = '2'; избира v2 rules engine (текущия). По-старите v1 правила са deprecated.
  • service cloud.firestore ограничава блока до Firestore. Realtime Database използва различен синтаксис, базиран на JSON; Cloud Storage използва service firebase.storage.
  • match /databases/{database}/documents свързва специалната база данни (default) (повечето проекти имат само една).
  • match /{document=**} е рекурсивен wildcard. ** съответства на всеки път с всяка дълбочина. Комбиниран с {document}, това улавя всеки документ във всяка колекция — единствена match клауза, управляваща цялата база данни.
  • allow read, write: if true; е тялото на правилото. Разрешени са както read, така и write; условието if true е, ами, винаги истина. read покрива операциите get и list; write покрива create, update и delete.

Нетен ефект: всеки клиент с Firebase project ID и правилния SDK може да чете или пише всеки документ във всяка колекция. Не се изисква автентикация. Не се налагат rate limits.

Защо Firebase изпраща това като по подразбиране

Firebase иска да кодирате в първите 30 секунди след създаването на проект. Алтернативата — да ви накара да напишете правилно правило, преди която и да е операция за четене или запис да работи — би блокирала onboarding-а. Затова Console предлага две опции, когато създадете база данни: Production mode (отказване на всичко, вие пишете правилата) или Test mode (разрешаване на всичко за 30 дни). Повечето разработчици щракат test mode, после забравят да го преразгледат. По-старите проекти имаха 30-дневен таймер; настоящите проекти имат безсрочно правило if true без автоматичен срок.

Структурният проблем: AI инструментите за кодиране се обучават върху документация, уроци и отговори в Stack Overflow, които показват test-mode правила. Когато попитате Cursor или Claude Code "как да настроя Firebase", отговорът често включва точно блока allow read, write: if true, сякаш това е production правилото. AI не знае — и не е подканен да знае — че това правило не е безопасно за продукция.

Какво вижда нападател

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

Една неавтентикирана curl заявка е достатъчна, за да изброи всяка колекция. Вижте маркирания блок по-долу.

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

Отговорът е пълният списък с колекции от най-високо ниво. За всяка колекция, втора заявка връща документи. Няма rate limit на този път, защото правилата if true приемат анонимен трафик. Видели сме Firebase бази данни с милиони документи, изброени за по-малко от час.

На пътя за запис: единичен POST с {fields} създава нов документ. Нападателите могат да замърсят вашите колекции с боклук, да обезобразят страници, обърнати към потребителите, които четат от Firestore, или да използват вашата база данни като безплатен message broker — сметката ви за употреба скача, разследвате, сметката обяснява проблема.

Четири замени, безопасни за продукция

Изберете заменителя, който съответства на модела на данни на приложението ви. И четирите предполагат, че имате потребителска автентикация (Firebase Auth или какъвто и да е доставчик, който издава Firebase ID token):

Опция 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: Поле за собственик на всеки документ

Когато документите живеят в плоски колекции (не вложени под user 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: Multi-tenant изолация на org

За B2B SaaS с org-обхватни данни. Съхранявайте поле org_id на всеки документ и го проверявайте срещу custom claim-а на потребителя. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Изисква задаването на custom claim по време на регистрация чрез Firebase Admin SDK.

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

Опция 4: Публично read-only съдържание

За маркетингово съдържание, публични профили, продуктови каталози — всичко, което наистина е публично за четене, но само admin може да пише. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Custom claim-ът admin е зададен само на admin акаунти.

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

Бърза одитна заявка

Преди да поправите, проверете дали if true е действително активно. Отворете Firebase Console → Firestore → Rules и потърсете if true. Ако го намерите където и да е извън коментар, имате откритие за отворено правило. Симулаторът на Rules в същия UI ви позволява да преиграете заявката на нападателя локално — поставете анонимно GET /users/somebody и потвърдете, че симулаторът връща Allowed.

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

Често задавани въпроси

Каква е разликата между <code>if true</code> и <code>if request.auth != null</code>?

if true позволява анонимен достъп — всеки в интернет. if request.auth != null изисква всеки влязъл потребител, което е по-добре, но все още погрешно: всеки потребител на приложението ви може да чете данните на всеки друг потребител. Production правилата трябва да се ограничат до конкретния потребител или org чрез request.auth.uid == resource.data.owner_uid или подобно.

Изтичат ли някога Firebase автоматично правилата <code>if true</code>?

По-старите проекти (преди 2023) имаха 30-дневен таймер, който конвертираше правилата if true в if false. Настоящите проекти не — правилото се запазва безсрочно, докато не бъде заменено ръчно. Ако сте създали проекта си преди 2023 и правилата ви изглеждат добре, проверете два пъти: таймерът може вече да ги е превключил на if false, което блокира собственото ви приложение.

Мога ли да използвам проверка с timestamp в бъдещето като предпазна мрежа?

Не — условие с timestamp не е контрол за сигурност. То изтича отвореното правило на бъдеща дата, което означава, че до тази дата нападателите имат пълен достъп. И ще забравите датата. Заменете if true с правило, ограничено по автентикация, не такова с времеви граници.

Какво ако моето приложение е наистина публично за четене (блог, продуктов каталог)?

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

Следващи стъпки

Изпълнете FixVibe сканиране срещу production URL — проверката baas.firebase-rules потвърждава дали if true в момента е експлоатируемо от публичния интернет. За механиката на скенера и паралелните детекции за Realtime Database и Storage, вижте Сканер за Firebase правила. За еквивалентния клас неправилна конфигурация в Supabase прочетете Сканер за Supabase RLS.

// сканирайте вашата baas повърхност

Намерете отворената таблица, преди някой друг да го направи.

Въведете production URL. FixVibe изброява доставчиците на BaaS, с които комуникира приложението ви, снема отпечатъци от публичните им крайни точки и докладва какво може да прочете или запише неавтентикиран клиент. Безплатно, без инсталация, без карта.

  • Безплатен план — 3 сканирания / месец, без карта при регистрация.
  • Пасивен отпечатък на BaaS — не се изисква проверка на домейн.
  • Supabase, Firebase, Clerk, Auth0, Appwrite и още.
  • AI промптове за поправка на всяко откритие — поставете обратно в Cursor / Claude Code.
Стартирайте безплатно BaaS сканиране →

не се изисква регистрация

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