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

Firebase allow read, write: if true ተብራራ፦ ምን እንደሚሰራና እንዴት እንደሚስተካከል

Q: በ if true እና if request.auth != null መካከል ያለው ልዩነት ምንድነው?

if true anonymous access ይፈቅዳል — በinternet ላይ ያለ ሁሉ። if request.auth != null ማንኛውም signed-in user ይፈልጋል፣ ይህም የተሻለ ቢሆንም አሁንም ስህተት ነው፦ የapp-ዎ ማንኛውም user የእያንዳንዱን ሌላ user data ሊያነብ ይችላል። Production rules በrequest.auth.uid == resource.data.owner_uid ወይም ተመሳሳይ የተወሰነ specific user ወይም org መሆን አለበት።

Q: Firebase if true rules ጊዜ ሲደርስ automatic expire ያደርጋል?

የቆዩ project-ዎች (pre-2023) if true rules-ን ወደ if false የሚቀይር የ30-ቀን timer ነበራቸው። አሁን ያሉ project-ዎች የላቸውም — rule በማንዋል እስኪተካ ድረስ indefinitely ይቆያል። Project-ዎን ከ2023 በፊት ከፈጠሩ እና rules-ዎ ጥሩ የሚመስለው ከሆነ፣ ሁለቴ ይፈትሹ፦ timer ሊቀይራቸው ይችላል ወደ if false፣ ይህም የራስዎን app ያግዳል።

Q: App-ዬ በትክክል public-read ከሆነ (blog፣ product catalog) ምን ይሆናል?

ከዚያ በግልጽ በpublic collection ብቻ allow read: if true; allow write: if false; ይጻፉ — በdatabase ውስጥ በእያንዳንዱ collection ላይ አይደለም። በcollection-ናቸው የተለየ match clause ይጠቀሙ እና recursive '{'document=**'}' wildcard-ን በwritable rules ላይ በፍጹም አይጠቀሙ።

<code>allow read, write: if true;</code> በproduction ላይ ብቸኛው እጅግ የተለመደ Firebase misconfiguration ነው። ይህ Firebase Console አዲስ database ሲፈጥሩ የሚጠቁመው test-mode default ነው፣ AI coding tool-ዎች ከdocumentation እንደገና የሚፈጥሩት rule ነው፣ እና ሙሉ Firestore database-ዎን ለinternet ላይ ላለ ሁሉ ሰው የሚከፍት rule ነው። ይህ ጽሑፍ syntax-ን በትክክል ያብራራል፣ ይህ rule ላይ ሲሆን attacker የሚያየውን ያሳያል፣ እና የተለያዩ ጥቅሞችን የሚስማሙ አራት progressively-stricter replacement ይሰጥዎታል።

Syntax፣ line by line

ሙሉ የFirestore test-mode rules document ስድስት line ነው፦

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 rules deprecated ነው።
service cloud.firestore block-ን ለFirestore ይወስናል። Realtime Database የተለየ JSON-based syntax ይጠቀማል፤ Cloud Storage service firebase.storage ይጠቀማል።
match /databases/{database}/documents ልዩ የ(default) database-ን (አብዛኞቹ project-ዎች አንድ ብቻ ነው ያላቸው) ይይዛል።
match /{document=**} recursive wildcard ነው። ** ማንኛውንም ጥልቀት ያለው ማንኛውንም path ይዛመዳል። ከ{document} ጋር ሲጣመር፣ ይህ በእያንዳንዱ collection ውስጥ የእያንዳንዱን document ይይዛል — ሙሉ database-ን የሚቆጣጠር አንድ match clause።
allow read, write: if true; የrule body ነው። ሁለቱም read እና write ይፈቀዳሉ፤ if true condition፣ ሁል ጊዜ true ነው። read get እና list operation ይሸፍናል፤ write create፣ update፣ እና delete ይሸፍናል።

አጠቃላይ ውጤት፦ የFirebase project ID እና ትክክለኛ SDK ያለው ማንኛውም client በማንኛውም collection ውስጥ ማንኛውንም document ሊያነብ ወይም ሊጽፍ ይችላል። Authentication አያስፈልገግም። Rate limit አይተገበርም።

Firebase ለምን ይህን እንደ default ይልካል

Firebase project ከፈጠሩ በመጀመሪያዎቹ 30 ሰከንዶች ውስጥ እንዲኮድ ይፈልጋል። አማራጭ — ማንኛውም read ወይም write ከመስራቱ በፊት ትክክለኛ rule እንዲጽፉ — onboarding-ን ያግድ ነበር። ስለዚህ Console database ሲፈጥሩ ሁለት options ይሰጣል፦ Production mode (ሁሉንም ይከለክሉ፣ rules እርስዎ ይጻፉ) ወይም Test mode (ለ30 ቀናት ሁሉንም ይፍቀዱ)። አብዛኞቹ developer-ዎች test mode-ን ይጫናሉ፣ ከዚያም ለመፈተሽ ይረሳሉ። የቆዩ project-ዎች የ30-ቀን timer ነበራቸው፤ አሁን ያሉ project-ዎች ያለ automatic expiry indefinite if true rule አላቸው።

Structural problem፦ AI coding tool-ዎች test-mode rules-ን በሚያሳዩ documentation፣ tutorial-ዎች እና Stack Overflow answer-ዎች ላይ ይሰለጥናሉ። Cursor ወይም Claude Code-ን "Firebase እንዴት እዘጋጅ" ስትጠይቅ፣ መልሱ ብዙውን ጊዜ ትክክለኛውን allow read, write: if true block እንደ production rule ያካተት ነው። AI-ው አያውቅም — እና ይህ rule ለproduction safe እንዳልሆነ እንዲያውቅ አይጠየቅም።

Attacker የሚያየው

በተጨባጭ፣ የFirebase project ID-ዎን (በ30 ሰከንዶች ውስጥ ከማንኛውም የተሰማራ app bundle ሊወጣ ይችላል) የሚያውቅ attacker ቀጥሎ ያለውን ሲያስኪድ በእያንዳንዱ collection ውስጥ የእያንዳንዱን document መuat ያደርጋል፦

አንድ unauthenticated curl request በቂ ነው እያንዳንዱን collection enumerate ለማድረግ። ከታች የተናተበውን block ይመልከቱ።

bash

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

Response የtop-level collection-ዎች ሙሉ list ነው። ለእያንዳንዱ collection፣ ሁለተኛ request document-ዎችን ይመልሳል። በዚህ path ላይ rate limit የለም ምክንያቱም if true rules anonymous traffic ይቀበላሉ። ሚሊዮኖች document-ዎች ያላቸውን Firebase database-ዎች ከአንድ ሰዓት ባነሰ ጊዜ ውስጥ enumerate ሲደረጉ አይተናል።

በwrite path ላይ፦ አንድ POST ከ{fields} ጋር አዲስ document ይፈጥራል። Attacker-ዎች collection-ዎችዎን በቆሻሻ ሊበክሉ፣ ከFirestore የሚያነቡ user-facing page-ዎችን ሊያቆሽሹ፣ ወይም database-ዎን እንደ ነጻ message broker ሊጠቀሙ ይችላሉ — የusage bill ይብላል፣ ይመረምራሉ፣ bill-ው ችግሩን ያብራራል።

አራት production-safe replacement-ዎች

ከapp data ሞዴል የሚስማማውን replacement ይምረጡ። አራቱም user authentication (Firebase Auth ወይም Firebase ID token የሚያወጣ ማንኛውም provider) እንዳለዎት ይገምታሉ፦

Option 1፦ User-owned document-ዎች

በብዛት የተለመደ SaaS pattern። Document-ዎች በ/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;
}

Option 2፦ በእያንዳንዱ document ላይ owner field

Document-ዎች በflat collection-ዎች ሲኖሩ (በuser ID ስር አይደለም)፣ owner_uid field ያከማቹ እና ይፈትሹት። 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;
}

Option 3፦ Multi-tenant org isolation

ለorg-scoped data ላለው B2B SaaS። በእያንዳንዱ document ላይ org_id field ያከማቹ እና ከuser custom claim ጋር ይፈትሹት። allow read, write: if request.auth.token.org_id == resource.data.org_id;። በsign-up ጊዜ በFirebase Admin SDK custom claim ማስቀመጥ ይፈልጋል።

firebase

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

Option 4፦ Read-only public content

ለmarketing content፣ public profile-ዎች፣ product catalog — በትክክል public-read ግን admin-only-write የሆነ ማንኛውም። match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }። የadmin custom claim በadmin account-ዎች ብቻ ይታስታል።

firebase

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

ፈጣን audit query

ከመስተካከል በፊት if true በትክክል live መሆኑን ይፈትሹ። Firebase Console → Firestore → Rules ይክፈቱ እና if true ይፈልጉ። ከcomment ውጭ ካገኙት፣ open-rule finding አለዎት። በተመሳሳዩ UI ውስጥ ያለ Rules simulator የattacker request-ን ላይ locally እንዲደግሙ ያስችላል — anonymous GET /users/somebody ይለጥፉ እና simulator Allowed መመለሱን ያረጋግጡ።

ውጫዊ ማረጋገጫ፦ በproduction URL-ዎ ላይ FixVibe scan ያስኪዱ። የbaas.firebase-rules check የFirestore፣ Realtime Database እና Storage rules-ዎችን ይመረምራል እና attacker የሚገኝውን ተመሳሳዩን finding ይዘግባል — Firebase Console የሚያሳየው ምን ቢሆን።

ብዙ ጊዜ የሚጠየቁ ጥያቄዎች

በ<code>if true</code> እና <code>if request.auth != null</code> መካከል ያለው ልዩነት ምንድነው?

if true anonymous access ይፈቅዳል — በinternet ላይ ያለ ሁሉ። if request.auth != null ማንኛውም signed-in user ይፈልጋል፣ ይህም የተሻለ ቢሆንም አሁንም ስህተት ነው፦ የapp-ዎ ማንኛውም user የእያንዳንዱን ሌላ user data ሊያነብ ይችላል። Production rules በrequest.auth.uid == resource.data.owner_uid ወይም ተመሳሳይ የተወሰነ specific user ወይም org መሆን አለበት።

Firebase <code>if true</code> rules ጊዜ ሲደርስ automatic expire ያደርጋል?

የቆዩ project-ዎች (pre-2023) if true rules-ን ወደ if false የሚቀይር የ30-ቀን timer ነበራቸው። አሁን ያሉ project-ዎች የላቸውም — rule በማንዋል እስኪተካ ድረስ indefinitely ይቆያል። Project-ዎን ከ2023 በፊት ከፈጠሩ እና rules-ዎ ጥሩ የሚመስለው ከሆነ፣ ሁለቴ ይፈትሹ፦ timer ሊቀይራቸው ይችላል ወደ if false፣ ይህም የራስዎን app ያግዳል።

Future-date timestamp check እንደ safety net ልጠቀም እችላለሁ?

አይ — timestamp condition security control አይደለም። ክፍት rule-ን በወደፊት ቀን expire ያደርጋል፣ ይህም ማለት እስከ ቀኑ ድረስ attacker-ዎች ሙሉ access አላቸው። እና ቀኑን ይረሳሉ። if true-ን በauth-scoped rule ይተኩት፣ time-bounded-ን አይደለም።

App-ዬ በትክክል public-read ከሆነ (blog፣ product catalog) ምን ይሆናል?

ከዚያ በግልጽ በpublic collection ብቻ allow read: if true; allow write: if false; ይጻፉ — በdatabase ውስጥ በእያንዳንዱ collection ላይ አይደለም። በcollection-ናቸው የተለየ match clause ይጠቀሙ እና recursive {document=**} wildcard-ን በwritable rules ላይ በፍጹም አይጠቀሙ።

ቀጣይ እርምጃዎች

በproduction URL-ዎ ላይ FixVibe scan ያስኪዱ — የbaas.firebase-rules check if true በአሁኑ ጊዜ ከpublic internet exploit-able መሆኑን ያረጋግጣል። ለscanner mechanics-ና ለRealtime Database እና Storage parallel detection-ዎች Firebase rules scanner ይመልከቱ። በSupabase ላይ ለሚስተካከለው የmisconfiguration class፣ Supabase RLS scanner ያንብቡ።