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

Firebase allow read, write: if true ipinaliwanag: ano ang ginagawa nito at paano ito ayusin

Q: Ano ang pagkakaiba ng if true at if request.auth != null ?

Ang if true ay nagpapahintulot sa anonymous access — sinuman sa internet. Ang if request.auth != null ay nangangailangan ng anumang signed-in user, na mas mabuti pero mali pa rin: sinumang user ng iyong app ay maaaring magbasa ng data ng bawat ibang user. Ang production rules ay dapat na naka-scope sa partikular na user o org sa pamamagitan ng request.auth.uid == resource.data.owner_uid o katulad nito.

Q: Paano kung ang aking app ay aktwal na public-read (blog, product catalog)?

Pagkatapos ay tahasan na isulat ang allow read: if true; allow write: if false; sa public collection lamang — hindi sa bawat collection sa iyong database. Gumamit ng hiwalay na match clause bawat collection at huwag kailanman gamitin ang recursive na '{'document=**'}' wildcard sa writable rules.

Ang <code>allow read, write: if true;</code> ay ang pinaka-karaniwang Firebase misconfiguration sa produksyon. Ito ang test-mode default na iminumungkahi ng Firebase Console kapag gumawa ka ng bagong database, ang rule na muling ginagawa ng AI coding tools mula sa documentation, at ang rule na nagbubukas ng iyong buong Firestore database sa sinuman sa internet. Ipinapaliwanag ng artikulong ito ang syntax nang tumpak, ipinapakita kung ano ang nakikita ng umaatake kapag aktibo ang rule na ito, at binibigyan ka ng apat na progresibo-mas-istrikto na mga kapalit na akma sa iba't ibang use cases.

Ang syntax, linya bawat linya

Ang isang kumpletong Firestore test-mode rules document ay anim na linya:

firebase

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

Naka-decode:

rules_version = '2'; ay pumipili ng v2 rules engine (kasalukuyan). Ang mga lumang v1 rules ay deprecated na.
service cloud.firestore ay nag-iiscope sa block sa Firestore. Ang Realtime Database ay gumagamit ng ibang JSON-based syntax; ang Cloud Storage ay gumagamit ng service firebase.storage.
match /databases/{database}/documents ay nagtatali sa espesyal na (default) database (karamihan ng mga project ay may isa lang).
match /{document=**} ay isang recursive wildcard. Ang ** ay tumutugma sa anumang path ng anumang lalim. Pinagsama sa {document}, kinukuha nito ang bawat dokumento sa bawat collection — isang iisang match clause na namamahala sa buong database.
allow read, write: if true; ay ang rule body. Pareho ang read at write ay pinahihintulutan; ang kondisyon na if true ay, mabuti, palaging true. Ang read ay sumasakop sa get at list operations; ang write ay sumasakop sa create, update, at delete.

Net effect: anumang client na may Firebase project ID at tamang SDK ay maaaring magbasa o magsulat ng anumang dokumento sa anumang collection. Ang authentication ay hindi kinakailangan. Ang rate limits ay hindi ipinapatupad.

Bakit ipinapadala ng Firebase ito bilang default

Gusto ng Firebase na nag-coding ka na sa unang 30 segundo pagkatapos gumawa ng project. Ang alternatibo — kailangan mong magsulat ng tamang rule bago gumana ang anumang read o write — ay haharangan ang onboarding. Kaya nag-aalok ang Console ng dalawang opsyon kapag gumawa ka ng database: Production mode (tanggihan ang lahat, ikaw ang nagsusulat ng rules) o Test mode (pahintulutan ang lahat ng 30 araw). Karamihan sa mga developer ay nag-click sa test mode, pagkatapos ay nakakalimutan nilang bisitahin muli. Ang mga lumang project ay may 30-araw na timer; ang kasalukuyang mga project ay may walang katapusan na if true rule na walang awtomatikong expiry.

Ang istrakturang problema: ang AI coding tools ay nag-aaral sa documentation, tutorials, at Stack Overflow answers na nagpapakita ng test-mode rules. Kapag nagtanong ka sa Cursor o Claude Code "paano ko i-setup ang Firebase," madalas na kasama sa sagot ang eksaktong allow read, write: if true block na para bang ito ang production rule. Hindi alam ng AI — at hindi pinapaalalahanan na malaman — na ang rule na ito ay hindi ligtas para sa produksyon.

Ano ang nakikita ng umaatake

Konkretong, ang isang umaatake na nakakaalam ng iyong Firebase project ID (makukuha mula sa bundle ng anumang naka-deploy na app sa 30 segundo) at nagpapatakbo ng sumusunod ay makakapag-list ng bawat dokumento sa bawat collection:

Ang isang iisang unauthenticated curl request ay sapat na upang ma-enumerate ang bawat collection. Tingnan ang naka-highlight na block sa ibaba.

bash

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

Ang response ay ang buong listahan ng mga top-level collections. Para sa bawat collection, ang isang ikalawang request ay nagbabalik ng mga dokumento. Walang rate limit sa path na ito dahil ang mga if true rules ay tumatanggap ng anonymous traffic. Nakita namin ang mga Firebase database na may milyon-milyong dokumento na na-enumerate sa wala pang isang oras.

Sa write path: ang iisang POST na may {fields} ay gumagawa ng bagong dokumento. Maaaring ipuno ng mga umaatake ang iyong mga collection ng basura, mag-deface ng mga user-facing pages na nagbabasa mula sa Firestore, o gamitin ang iyong database bilang libreng message broker — biglang taas ng iyong usage bill, sinisiyasat mo ito, ipinapaliwanag ng bill ang problema.

Apat na production-safe na kapalit

Piliin ang kapalit na tumutugma sa data model ng iyong app. Ang lahat ng apat ay ipinapalagay na mayroon kang user authentication (Firebase Auth o anumang provider na naglalabas ng Firebase ID token):

Opsyon 1: User-owned na mga dokumento

Pinaka-karaniwang SaaS pattern. Ang mga dokumento ay nasa ilalim ng /users/{userId}/... at tanging ang may-ari ang makakahawak sa kanila. 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;
}

Opsyon 2: Owner field sa bawat dokumento

Kapag ang mga dokumento ay nasa flat collections (hindi naka-nest sa ilalim ng user ID), mag-imbak ng owner_uid field at i-check ito. 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;
}

Opsyon 3: Multi-tenant org isolation

Para sa B2B SaaS na may org-scoped data. Mag-imbak ng org_id field sa bawat dokumento at i-check ito laban sa custom claim ng user. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Nangangailangan ng pagtakda ng custom claim sa sign-up sa pamamagitan ng Firebase Admin SDK.

firebase

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

Opsyon 4: Read-only public content

Para sa marketing content, public profiles, product catalogs — anumang aktwal na public-read pero admin-only-write. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Ang admin custom claim ay itinatakda sa mga admin account lamang.

firebase

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

Mabilisang audit query

Bago ayusin, tingnan kung ang if true ay aktwal na buhay. Buksan ang Firebase Console → Firestore → Rules at hanapin ang if true. Kung mahanap mo ito kahit saan sa labas ng comment, mayroon kang open-rule finding. Ang Rules simulator sa parehong UI ay nagpapahintulot sa iyong i-replay ang request ng umaatake lokal — i-paste ang isang anonymous na GET /users/somebody at kumpirmahin na nagbabalik ang simulator ng Allowed.

Panlabas na kumpirmasyon: magpatakbo ng FixVibe scan laban sa iyong production URL. Ang baas.firebase-rules check ay nagpo-probe sa iyong Firestore, Realtime Database, at Storage rules at iniuulat ang parehong finding na matutuklasan ng umaatake — independyente sa kung ano ang ipinapakita ng Firebase Console.

Mga madalas na itinatanong

Ano ang pagkakaiba ng <code>if true</code> at <code>if request.auth != null</code>?

Ang if true ay nagpapahintulot sa anonymous access — sinuman sa internet. Ang if request.auth != null ay nangangailangan ng anumang signed-in user, na mas mabuti pero mali pa rin: sinumang user ng iyong app ay maaaring magbasa ng data ng bawat ibang user. Ang production rules ay dapat na naka-scope sa partikular na user o org sa pamamagitan ng request.auth.uid == resource.data.owner_uid o katulad nito.

Ang Firebase ba ay kusang nag-e-expire ng mga <code>if true</code> rules?

Ang mga lumang project (pre-2023) ay may 30-day timer na nag-co-convert ng mga if true rules sa if false. Ang mga kasalukuyang project ay hindi — ang rule ay nananatiling walang katapusan hanggang manwal na mapalitan. Kung gumawa ka ng iyong project bago ang 2023 at mukhang ayos ang iyong rules, suriin nang doble: maaaring inay-flip na ng timer ang mga ito sa if false, na hinaharangan ang iyong sariling app.

Maaari ba akong gumamit ng future-date timestamp check bilang safety net?

Hindi — ang timestamp condition ay hindi isang security control. Ina-expire nito ang bukas na rule sa isang petsa sa hinaharap, na nangangahulugang hanggang sa petsang iyon ang mga umaatake ay may buong access. At makakalimutan mo ang petsa. Palitan ang if true ng auth-scoped na rule, hindi ng oras-na-limitadong rule.

Paano kung ang aking app ay aktwal na public-read (blog, product catalog)?

Pagkatapos ay tahasan na isulat ang allow read: if true; allow write: if false; sa public collection lamang — hindi sa bawat collection sa iyong database. Gumamit ng hiwalay na match clause bawat collection at huwag kailanman gamitin ang recursive na {document=**} wildcard sa writable rules.

Mga susunod na hakbang

Magpatakbo ng FixVibe scan laban sa iyong production URL — ang baas.firebase-rules check ay nagkukumpirma kung ang if true ay kasalukuyang exploitable mula sa pampublikong internet. Para sa scanner mechanics at parallel detections para sa Realtime Database at Storage, tingnan ang Firebase rules scanner. Para sa katumbas na klase ng misconfiguration sa Supabase, basahin ang Supabase RLS scanner.