Firebase rules scanner: hanapin ang mga bukas na Firestore, Realtime Database, at Storage rules

Paano nakakahanap ng mga bukas na Firebase rules ang scanner

Ang mga Firebase services ay nag-e-expose ng kilala at predictable na URL shapes. Maaaring mag-probe sa bawat isa ang isang scanner na walang credentials at obserbahan kung nagtatagumpay ang mga anonymous reads. Ang baas.firebase-rules check ng FixVibe ay tumatakbo sa tatlong independent probes — isa bawat 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. Nagpo-probe ang scanner sa https://[project-id]-default-rtdb.firebaseio.com/.json. Kung ang root ay nababasa nang anonymous, ang response ay ang buong database tree bilang JSON. Ang isang mas konserbatibong test ay nag-query ng .json?shallow=true, na nagbabalik ng top-level keys lamang — isang finding sa alinmang paraan.
• Cloud Storage. Nag-query ang scanner sa https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Kung ang response ay nagla-list ng mga file names nang walang authentication, ang bucket ay anon-listable. Ang listable storage ay isang finding kahit na ang mga indibidwal na file downloads ay ipinagbabawal — ine-enumerate ng mga umaatake ang bucket upang mahanap ang mga mahuhulaan na filenames.

Ano talaga ang itsura ng test-mode footgun

Ang quickstart documentation ng Firebase ay naglalaman ng isa sa pinaka-kinokopyang rule blocks sa internet:

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

Ang Firebase ay dating nagdadagdag ng awtomatikong 30-araw na expiry sa mga rules na ito. Nagbago iyon: ngayon ang mga rules ay nananatiling walang katapusan maliban kung papalitan ng developer. Ang AI coding tools — na nasanay sa mga taon ng documentation na may kasamang test-mode block — ay madalas naglalabas nito nang verbatim at sinasabi sa developer na "ito ang iyong security rule." Hindi ito.

Iba pang variants na lumalabas sa produksyon ngunit pantay na permissive:

// 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;

• Isang future-timestamp variant: isang rule na nagpapahintulot ng lahat hanggang sa isang petsa sa malayong hinaharap. Hindi kailanman epektibong nag-e-expire (tingnan ang naka-highlight na block sa itaas).
• allow read: if true; allow write: if request.auth != null; — public reads, anumang authenticated user ay makakapagsulat.
• allow read, write: if request.auth != null; — anumang signed-in user ay makakabasa o makakapagsulat ng anumang dokumento, kasama ang data ng ibang users.

Ano ang gagawin kapag may natuklasang bukas na rule ang scanner

Ang mga bukas na Firebase rules ay isang runtime emergency. Pareho ang hugis ng pag-aayos sa lahat ng tatlong services: i-scope ang bawat rule sa request.auth.uid laban sa tahasang owner field. Ang bawat service ay may sarili nitong rule syntax:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Ang path-segment binding na {userId} ay nagiging ang tanging dokumento na maaaring hawakan ng user.

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.

{
  "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; } } }. Convention: mag-imbak ng files sa ilalim ng users/[uid]/[filename] at hayaan ang path na mag-enforce ng ownership.

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

I-deploy ang rules sa pamamagitan ng Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. I-verify na ang mga bagong rules ay nasa produksyon sa pamamagitan ng muling pagpapatakbo ng FixVibe scan — dapat nang mawala ang baas.firebase-rules finding.

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

Paano ito naihahambing sa built-in tools ng Firebase

Ipinapakita ng Firebase Console ang kasalukuyang rules ngunit hindi sila ina-audit laban sa runtime behaviour. Ang Firebase Rules simulator ay nagpapahintulot sa iyong i-test ang rule logic laban sa synthetic requests — kapaki-pakinabang ngunit lokal. Walang isa sa mga ito ang nagsasabi sa iyo kung ano ang aktwal na ibinabalik ng iyong production rules sa isang anonymous attacker sa pampublikong internet. Ang isang external scanner tulad ng FixVibe (o Burp Suite na may manwal na konpigurasyon) ang tanging bagay na nagpo-probe mula sa parehong anggulo na gagamitin ng umaatake. Ang sariling App Check ng Google ay nakakapag-mitigate ng pang-aabuso ngunit hindi pamalit sa wastong na-scope na rules.

Mga madalas na itinatanong

Mga susunod na hakbang

Magpatakbo ng libreng FixVibe scan laban sa iyong production URL — ang baas.firebase-rules check ay nag-de-deploy sa bawat plan at nagba-flag ng mga bukas na rules sa Firestore, Realtime Database, at Cloud Storage. Para sa mas malalim na pagpapaliwanag ng allow read, write: if true pattern partikular, tingnan ang Firebase allow read, write: if true ipinaliwanag. Para sa pangkalahatang tanaw sa Supabase, Firebase, Clerk, at Auth0, basahin ang BaaS misconfiguration scanner.