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 → Firestore → Rules і шукайце if true. Калі вы знойдзеце яго дзе-небудзь па-за каментарыем, у вас ёсць знаходка адкрытага правіла. Сімулятар правіл у тым жа UI дазваляе вам прайграваць запыт зламысніка лакальна — устаўце ананімны GET /users/somebody і пацвердзіце, што сімулятар вяртае Дазволена.

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

Часта задаваныя пытанні

Наступныя крокі

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