// docs / baas security / firebase rules scanner

Firebase rules scanner፦ ክፍት Firestore፣ Realtime Database እና Storage rules-ን ይፈልጉ

Name: Firebase rules scanner፦ ክፍት Firestore፣ Realtime Database እና Storage rules-ን ይፈልጉ
Brand: FixVibe
Author: FixVibe

Firebase app-ዎች በአንድ ተመሳሳዩ መንገድ security ይወድቃሉ፦ ከtest-mode quickstart የቀሩ <code>allow read, write: if true;</code> rules፣ ከproduction በፊት በፍጹም አልተተኩም። AI coding tool-ዎች እነዚህ rules-ን ከdocumentation example-ዎች በቅጁ ይፈጥራሉ እና developer-ውን እንዲያጠናክራቸው ብዙውን ጊዜ አይጠይቁም። ይህ ጽሑፍ Firebase rules scanner Firestore፣ Realtime Database እና Cloud Storage ውስጥ ክፍት rules-ን ከproject ውጭ እንዴት እንደሚለይ ያሳያል — እና የተገኘውን እንዴት እንደሚስተካከል።

Scanner ክፍት Firebase rules እንዴት እንደሚያገኝ

Firebase service-ዎች well-known፣ predictable URL shape-ዎችን ያጋልጣሉ። ያለ credential scanner እያንዳንዱን ሊመረምር እና anonymous read-ዎች መሳካታቸውን መታዘብ ይችላል። የFixVibe baas.firebase-rules check በሦስት ገለልተኛ probe ይሰራል — በFirebase service-ናቸው፦

<strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
Realtime Database። Scanner-ው https://[project-id]-default-rtdb.firebaseio.com/.json-ን ይመረምራል። Root anonymously የሚነበብ ከሆነ፣ response ሙሉው database tree እንደ JSON ነው። ይበልጥ ጥንቃቄ የተሞላበት ፈተና .json?shallow=true ይጠይቃል፣ ይህም top-level key-ዎችን ብቻ ይመልሳል — በሁለቱም መንገድ finding ነው።
Cloud Storage። Scanner-ው https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o-ን ይጠይቃል። Response ያለ authentication file ስሞችን ቢlist ያደርግ፣ bucket anon-listable ነው። የግለሰብ file download-ዎች ቢከለከሉም listable storage finding ነው — attacker-ዎች guessable filename ለማግኘት bucket-ን enumerate ያደርጋሉ።

Test-mode footgun በትክክል እንዴት እንደሚታይ

የFirebase quickstart documentation በinternet ላይ ከበለጠ የተቀዱ rule block ውስጥ አንዱን ያካትታል፦

firebase

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

Firebase በእነዚህ rules ላይ automatic 30-day expiry ይጨምር ነበር። ይህ ተለውጧል፦ ዛሬ rules developer-ው እስከሚተካቸው ድረስ ለዘላለም ይቆያሉ። AI coding tool-ዎች — የtest-mode block ያካተተ documentation ላይ ላለፉት ዓመታት የተሰለጠኑ — በቅጁ ብዙውን ጊዜ ይልኩትና ለdeveloper "ይህ የእርስዎ security rule ነው" ይሉታል። አይደለም።

በproduction ላይ የሚታዩ ሌሎች variant-ዎች ግን በተመሳሳይ permissive የሆኑ፦

firebase

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

Future-timestamp variant፦ ሁሉንም እስከ ሩቅ የወደፊት ቀን ድረስ የሚፈቅድ rule። በፍጹም effective expire አያደርግም (ከላይ የተናተበውን block ይመልከቱ)።
allow read: if true; allow write: if request.auth != null; — public reads፣ ማንኛውም authenticated user መጻፍ ይችላል።
allow read, write: if request.auth != null; — ማንኛውም signed-in user ማንኛውንም document ሊያነብ ወይም ሊጽፍ ይችላል፣ የሌሎች user-ዎችን data ጨምሮ።

Scanner ክፍት rule ሲያገኝ ምን ማድረግ

ክፍት Firebase rules-ዎች የruntime አደጋ ናቸው። መፍትሄው በሁሉም ሦስት service-ዎች ተመሳሳዩ shape ነው፦ እያንዳንዱን rule በrequest.auth.uid ላይ ግልጽ owner field በማነጻጸር ይወስኑ። እያንዳንዱ service የራሱ rule syntax አለው፦

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }። የpath-segment binding {userId} user-ው ሊነካው የሚችለው ብቸኛ document ይሆናል።

firebase

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

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

json

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }። ስምምነት፦ file-ዎችን በusers/[uid]/[filename] ስር ያከማቹ እና path ownership-ን ያስፈጽም።

firebase

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Rules በFirebase CLI ይዘርጉ፦ firebase deploy --only firestore:rules፣ firebase deploy --only database፣ firebase deploy --only storage። አዲሶቹ rules በproduction መሆኑን FixVibe scan እንደገና በማስኪድ ያረጋግጡ — የbaas.firebase-rules finding መጥፋት አለበት።

bash

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

ይህ ከFirebase built-in tool-ዎች ጋር እንዴት ይነጻጸራል

Firebase Console አሁን ያሉትን rules ያሳያል ነገር ግን ከruntime ባህሪ ጋር audit አያደርጋቸውም። የFirebase Rules simulator rule logic-ን ከsynthetic request-ዎች ጋር ለመፈተን ያስችላል — ጠቃሚ ግን local ነው። ሁለቱም tool-ዎች የproduction rules-ዎ ለinternet ላይ anonymous attacker የሚመለሰው ምን እንደሆነ አይነግሩዎትም። እንደ FixVibe ያለ ውጫዊ scanner (ወይም በማንዋል configuration Burp Suite) attacker ከሚመረምርበት ተመሳሳዩ ጎን ብቸኛ መርማሪ ነው። Google የራሱ App Check abuse-ን ይቀንሳል ግን ለትክክለኛ-ስውር rules ምትክ አይደለም።

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

Scanner የFirestore data-ዬን ያነባል ወይም ይቀይራል?

Passive scan-ዎች rules-ዎች መፍቀዳቸውን ለማረጋገጥ በservice-ናቸው ቢበዛ አንድ anonymous read ያስኪዳሉ። Scanner-ው response shape እና data መኖሩን ይመዘግባል — paginate አያደርግም፣ document enumerate አያደርግም፣ መጻፍ የለበትም። Write probe-ዎች በተረጋገጠ domain ownership የተወሰኑ ሲሆኑ በፍጹም ባልተረጋገጡ target-ዎች ላይ አይሰሩም።

የFirebase project-ዬ App Check የሚጠቀም ከሆነ ምን ይሆናል?

App Check unauthenticated request-ዎችን በ403 ይከለክላል። ያለ App Check token scanner በእያንዳንዱ probe ላይ 403 ያያል — ይህም ትክክለኛ outcome ነው። App Check ለrule correctness ምትክ አይደለም (የተሰረቀ App Check token ከክፍት rule ጋር አሁንም data ያፈሳል)፣ ግን አጋጣሚያዊ ውጫዊ scan-ዎችን ይከለክላል።

Scanner ከፊል rule misconfiguration-ዎችን (read open፣ write closed) ሊለይ ይችላል?

አዎ — እያንዳንዱ rule (allow read፣ allow write) በተናጠል ይመረመራል። በ200 OK የሚሳካ read-only probe writes ቢከለክሉም open-read finding ይዘግባል። ሁለቱ findings የተለያዩ ናቸው፦ data exfiltration እና data manipulation የተለያዩ risk ናቸው።

ይህ በcustom domain ስር ለተሰማራ Firebase app ይሰራል?

አዎ። Scanner-ው የFirebase project ID-ን ከtaught domain ሳይሆን ከተሰማራው bundle ያወጣል። Custom domains፣ app.web.app subdomains እና self-hosted Firebase app-ዎች የJavaScript bundle ሊደረስ እስከቆየ ሁሉም በተመሳሳይ መንገድ ይሰራሉ።

ቀጣይ እርምጃዎች

በproduction URL-ዎ ላይ ነጻ FixVibe scan ያስኪዱ — የbaas.firebase-rules check በእያንዳንዱ plan ላይ ይላካል እና በFirestore፣ Realtime Database እና Cloud Storage ላይ ክፍት rules-ን ይሰምራል። ስለallow read, write: if true pattern ጥልቅ ለማንበብ Firebase allow read, write: if true ተብራራ ይመልከቱ። በSupabase፣ Firebase፣ Clerk እና Auth0 ላይ ለመስፋት እይታ፣ BaaS misconfiguration scannerን ያንብቡ።