Firebase rules scanner: खुले Firestore, Realtime Database, और Storage rules ढूँढ़ें

Scanner खुले Firebase rules कैसे ढूँढ़ता है

Firebase services well-known, predictable URL shapes expose करती हैं। बिना credentials के एक scanner हर एक को probe कर सकता है और observe कर सकता है कि anonymous reads सफल होती हैं या नहीं। FixVibe baas.firebase-rules check तीन स्वतंत्र probes में चलता है — प्रति 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 को probe करता है। यदि root anonymously readable है, तो response JSON के रूप में पूरा database tree है। एक अधिक conservative test .json?shallow=true को query करता है, जो केवल top-level keys लौटाता है — किसी भी तरह से एक finding।
• Cloud Storage. Scanner https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o को query करता है। यदि response बिना authentication file नाम सूचीबद्ध करता है, तो bucket anon-listable है। Listable storage एक finding है भले ही व्यक्तिगत file downloads को deny किया जाए — हमलावर guessable filenames खोजने के लिए bucket को enumerate करते हैं।

Test-mode footgun वास्तव में कैसा दिखता है

Firebase के quickstart documentation में इंटरनेट पर सबसे अधिक copy किए गए rule blocks में से एक शामिल है:

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

Firebase इन rules पर एक automatic 30-दिन expiry जोड़ता था। यह बदल गया: आज rules हमेशा के लिए बने रहते हैं जब तक developer उन्हें replace नहीं करता। AI कोडिंग टूल — जो वर्षों के documentation पर प्रशिक्षित हैं जिसमें test-mode block शामिल है — अक्सर इसे verbatim emit करते हैं और developer को बताते हैं "यह आपका security rule है।" यह नहीं है।

अन्य variants जो production में दिखाई देते हैं पर समान रूप से 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;

• एक future-timestamp variant: एक rule जो दूर भविष्य की तारीख तक सब कुछ अनुमति देता है। कभी प्रभावी रूप से 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 को पढ़ या लिख सकता है, अन्य users के data सहित।

जब scanner एक खुला rule ढूँढ़े तो क्या करें

खुले Firebase rules एक runtime emergency हैं। फ़िक्स सभी तीन services में समान आकार का है: हर rule को एक स्पष्ट owner field के विरुद्ध request.auth.uid पर scope करें। हर service की अपनी rule syntax है:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }। Path-segment binding {userId} वही एकमात्र document बन जाता है जिसे 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: users/[uid]/[filename] के तहत files store करें और path को ownership लागू करने दें।

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

Firebase CLI के माध्यम से rules deploy करें: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage। FixVibe scan फिर से चलाकर verify करें कि नए rules production में हैं — baas.firebase-rules finding साफ़ हो जानी चाहिए।

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

यह Firebase के अंतर्निहित टूल की तुलना में कैसा है

Firebase Console आपको current rules दिखाता है पर उन्हें runtime behaviour के विरुद्ध audit नहीं करता। Firebase Rules simulator आपको synthetic requests के विरुद्ध rule logic का परीक्षण करने देता है — उपयोगी पर local। कोई भी टूल आपको यह नहीं बताता कि आपके production rules public इंटरनेट पर एक anonymous हमलावर को वास्तव में क्या लौटाते हैं। FixVibe जैसा एक बाहरी scanner (या manual configuration वाला Burp Suite) ही एकमात्र चीज़ है जो उसी कोण से probe करती है जिससे एक हमलावर करेगा। Google का अपना App Check abuse को कम करता है पर सही ढंग से-scoped rules का substitute नहीं है।

अक्सर पूछे जाने वाले प्रश्न

अगले कदम

अपने production URL के विरुद्ध एक मुफ़्त FixVibe scan चलाएँ — baas.firebase-rules check हर plan पर ship होता है और Firestore, Realtime Database, और Cloud Storage में खुले rules को फ़्लैग करता है। allow read, write: if true pattern पर विशेष रूप से एक गहन व्याख्याकार के लिए, Firebase allow read, write: if true explained देखें। Supabase, Firebase, Clerk, और Auth0 में umbrella दृश्य के लिए, BaaS misconfiguration scanner पढ़ें।