// docs / baas security / firebase rules scanner

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

Q: क्या होगा यदि मेरा Firebase project App Check का उपयोग करता है?

App Check unauthenticated requests को 403 के साथ अस्वीकार करता है। App Check token के बिना एक scanner हर probe पर 403 देखेगा — जो सही outcome है। App Check rule correctness का substitute नहीं है (एक चोरी हुआ App Check token साथ एक खुला rule अभी भी data leak करता है), पर यह opportunistic बाहरी scans को block करता है।

Firebase apps एक सुसंगत तरीके से security में fail होती हैं: test-mode quickstart से बचे हुए allow read, write: if true; rules, जिन्हें production से पहले कभी replace नहीं किया गया। AI कोडिंग टूल documentation examples से इन rules को verbatim generate करते हैं और developer को इन्हें harden करने के लिए शायद ही कभी prompt करते हैं। यह लेख दिखाता है कि एक Firebase rules scanner project के बाहर से Firestore, Realtime Database, और Cloud Storage में खुले rules कैसे detect करता है — और जो पाया जाता है उसे कैसे फ़िक्स करें।

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

Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:

Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
Realtime Database. FixVibe reports a database whose data anonymous visitors can read — often the whole tree at once.
Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.

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

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

firebase

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 हैं:

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 जो दूर भविष्य की तारीख तक सब कुछ अनुमति देता है। कभी प्रभावी रूप से 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 छू सकता है।

firebase

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

रीयलटाइम डेटाबेस

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }। $uid wildcard तुलना के लिए path segment को capture करता है।

json

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

क्लाउड स्टोरेज

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 लागू करने दें।

firebase

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

Deploy rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan — the open-rules finding should clear.

bash

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 नहीं है।

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

क्या scanner मेरा Firestore data पढ़ता या modify करता है?

Passive scans प्रति service अधिकतम एक anonymous read issue करते हैं ताकि confirm किया जा सके कि rules इसकी अनुमति देते हैं या नहीं। Scanner response shape और data की उपस्थिति record करता है — यह paginate नहीं करता, documents को enumerate नहीं करता, और लिखता नहीं। Write probes verified domain ownership के पीछे gated हैं और कभी भी unverified targets के विरुद्ध नहीं चलते।

क्या होगा यदि मेरा Firebase project App Check का उपयोग करता है?

App Check unauthenticated requests को 403 के साथ अस्वीकार करता है। App Check token के बिना एक scanner हर probe पर 403 देखेगा — जो सही outcome है। App Check rule correctness का substitute नहीं है (एक चोरी हुआ App Check token साथ एक खुला rule अभी भी data leak करता है), पर यह opportunistic बाहरी scans को block करता है।

क्या scanner partial rule misconfigurations (read खुला, write बंद) detect कर सकता है?

Yes. Open read access and open write access are reported as separate findings, because data exfiltration and data manipulation are separate risks.

क्या यह custom domain के तहत deployed Firebase apps के लिए काम करता है?

हाँ। Scanner deployed bundle से Firebase project ID निकालता है, domain से नहीं। Custom domains, app.web.app subdomains, और self-hosted Firebase apps सभी एक ही तरह से काम करते हैं जब तक JavaScript bundle reachable है।

अगले कदम

Run a free FixVibe scan against your production URL — the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.