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

Firebase allow read, write: if true समझाया गया: यह क्या करता है और इसे कैसे फ़िक्स करें

Q: if true और if request.auth != null के बीच क्या अंतर है?

if true anonymous access की अनुमति देता है — इंटरनेट पर कोई भी। if request.auth != null को किसी भी signed-in user की आवश्यकता होती है, जो बेहतर है पर अभी भी गलत है: आपकी app का कोई भी user हर दूसरे user का data पढ़ सकता है। Production rules को request.auth.uid == resource.data.owner_uid या इसी तरह के माध्यम से विशिष्ट user या org तक scope करना चाहिए।

Q: क्या Firebase कभी if true rules को automatically expire करता है?

पुराने projects (2023 से पहले) में 30-दिन का timer था जो if true rules को if false में बदल देता था। Current projects में नहीं — rule manually replace होने तक अनिश्चित काल तक बना रहता है। यदि आपने अपना project 2023 से पहले बनाया था और आपके rules ठीक दिखते हैं, तो दोहरी जाँच करें: timer ने उन्हें पहले ही if false में flip कर दिया हो सकता है, जो आपकी अपनी app को block कर देगा।

Q: क्या होगा यदि मेरी app वास्तव में public-read (blog, product catalog) है?

तो स्पष्ट रूप से allow read: if true; allow write: if false; केवल public collection पर लिखें — अपने database के हर collection पर नहीं। प्रति collection एक अलग match clause का उपयोग करें और writable rules पर कभी recursive '{'document=**'}' wildcard का उपयोग न करें।

<code>allow read, write: if true;</code> production में सबसे आम Firebase misconfiguration है। यह वह test-mode default है जिसे Firebase Console तब सुझाता है जब आप एक नया database बनाते हैं, वह rule जिसे AI कोडिंग टूल documentation से पुनः generate करते हैं, और वह rule जो आपके पूरे Firestore database को इंटरनेट पर किसी को भी खोल देता है। यह लेख syntax को सटीक रूप से समझाता है, दिखाता है कि एक हमलावर को क्या दिखता है जब यह rule live है, और आपको चार प्रगतिशील-कठोर replacements देता है जो विभिन्न use cases में फ़िट होते हैं।

Syntax, line by line

एक पूर्ण Firestore test-mode rules document छह lines का है:

firebase

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

Decoded:

rules_version = '2'; v2 rules engine (current) का चयन करता है। पुराने v1 rules deprecated हैं।
service cloud.firestore block को Firestore तक scope करता है। Realtime Database एक अलग JSON-आधारित syntax का उपयोग करता है; Cloud Storage service firebase.storage का उपयोग करता है।
match /databases/{database}/documents special (default) database को bind करता है (अधिकांश projects में केवल एक होता है)।
match /{document=**} एक recursive wildcard है। ** किसी भी गहराई के किसी भी path से मेल खाता है। {document} के साथ संयुक्त, यह हर collection के हर document को capture करता है — एक एकल match clause जो पूरे database को govern करता है।
allow read, write: if true; rule body है। read और write दोनों की अनुमति है; condition if true, खैर, हमेशा true है। read get और list operations को cover करता है; write create, update, और delete को cover करता है।

शुद्ध प्रभाव: Firebase project ID और सही SDK वाला कोई भी client किसी भी collection के किसी भी document को पढ़ या लिख सकता है। Authentication की आवश्यकता नहीं है। Rate limits लागू नहीं हैं।

Firebase इसे default के रूप में क्यों ship करता है

Firebase चाहता है कि आप एक project बनाने के पहले 30 सेकंड में कोडिंग कर रहे हों। विकल्प — आपसे कोई भी read या write काम करने से पहले एक सही rule लिखवाना — onboarding को block कर देगा। इसलिए जब आप एक database बनाते हैं तो Console दो विकल्प प्रदान करता है: Production mode (सब कुछ deny करें, आप rules लिखें) या Test mode (30 दिनों के लिए सब कुछ अनुमति दें)। अधिकांश developers test mode पर click करते हैं, फिर वापस जाना भूल जाते हैं। पुराने projects में 30-दिन का timer था; current projects में बिना automatic expiry के एक अनिश्चित if true rule है।

Structural समस्या: AI कोडिंग टूल documentation, tutorials, और Stack Overflow answers पर प्रशिक्षित होते हैं जो test-mode rules दिखाते हैं। जब आप Cursor या Claude Code से पूछते हैं "मैं Firebase कैसे सेट करूँ," उत्तर में अक्सर सटीक allow read, write: if true block शामिल होता है मानो यह production rule हो। AI नहीं जानता — और जानने के लिए prompt नहीं किया जाता — कि यह rule production के लिए सुरक्षित नहीं है।

एक हमलावर को क्या दिखता है

ठोस रूप से, एक हमलावर जो आपके Firebase project ID को जानता है (किसी भी deployed app के bundle से 30 सेकंड में निकाला जा सकता है) और निम्नलिखित चलाता है, हर collection के हर document को list कर सकता है:

एक एकल 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 collections की पूरी सूची है। हर collection के लिए, एक दूसरी request documents लौटाती है। इस path पर कोई rate limit नहीं है क्योंकि if true rules anonymous traffic स्वीकार करते हैं। हमने Firebase databases को एक घंटे से कम में लाखों documents के साथ enumerated देखा है।

Write path पर: {fields} के साथ एक एकल POST एक नया document बनाता है। हमलावर आपके collections को कचरे से प्रदूषित कर सकते हैं, Firestore से पढ़ने वाले user-facing pages को deface कर सकते हैं, या आपके database को एक मुफ़्त message broker के रूप में उपयोग कर सकते हैं — आपका usage bill बढ़ता है, आप जाँच करते हैं, bill समस्या समझाता है।

चार production-safe replacements

वह replacement चुनें जो आपके app के data model से मेल खाता हो। सभी चार मानते हैं कि आपके पास user authentication है (Firebase Auth या कोई provider जो एक Firebase ID token जारी करता है):

Option 1: User-owned documents

सबसे आम SaaS pattern। Documents /users/{userId}/... के तहत रहते हैं और केवल owner उन्हें छू सकता है। 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

जब documents flat collections में रहते हैं (user ID के तहत nested नहीं), एक owner_uid field store करें और इसे check करें। 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 store करें और इसे user के custom claim के विरुद्ध check करें। allow read, write: if request.auth.token.org_id == resource.data.org_id;। Firebase Admin SDK के माध्यम से sign-up के दौरान 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 profiles, product catalogs के लिए — कुछ भी जो वास्तव में public-read है पर admin-only-write है। match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }। admin custom claim केवल admin accounts पर सेट होता है।

firebase

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

त्वरित audit query

फ़िक्स करने से पहले, check करें कि if true वास्तव में live है या नहीं। Firebase Console → Firestore → Rules खोलें और if true खोजें। यदि आप इसे एक comment के बाहर कहीं भी पाते हैं, तो आपके पास एक open-rule finding है। उसी UI में Rules simulator आपको हमलावर की request को locally replay करने देता है — एक anonymous GET /users/somebody paste करें और confirm करें कि simulator Allowed लौटाता है।

बाहरी confirmation: अपने production URL के विरुद्ध एक FixVibe scan चलाएँ। baas.firebase-rules check आपके Firestore, Realtime Database, और Storage rules को probe करता है और वही finding report करता है जो एक हमलावर खोजेगा — Firebase Console जो दिखाता है उससे स्वतंत्र।

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

<code>if true</code> और <code>if request.auth != null</code> के बीच क्या अंतर है?

if true anonymous access की अनुमति देता है — इंटरनेट पर कोई भी। if request.auth != null को किसी भी signed-in user की आवश्यकता होती है, जो बेहतर है पर अभी भी गलत है: आपकी app का कोई भी user हर दूसरे user का data पढ़ सकता है। Production rules को request.auth.uid == resource.data.owner_uid या इसी तरह के माध्यम से विशिष्ट user या org तक scope करना चाहिए।

क्या Firebase कभी <code>if true</code> rules को automatically expire करता है?

पुराने projects (2023 से पहले) में 30-दिन का timer था जो if true rules को if false में बदल देता था। Current projects में नहीं — rule manually replace होने तक अनिश्चित काल तक बना रहता है। यदि आपने अपना project 2023 से पहले बनाया था और आपके rules ठीक दिखते हैं, तो दोहरी जाँच करें: timer ने उन्हें पहले ही if false में flip कर दिया हो सकता है, जो आपकी अपनी app को block कर देगा।

क्या मैं एक future-date timestamp check को सुरक्षा जाल के रूप में उपयोग कर सकता हूँ?

नहीं — एक timestamp condition एक security control नहीं है। यह खुले rule को एक भविष्य की तारीख पर expire करता है, जिसका मतलब उस तारीख तक हमलावरों के पास पूर्ण access है। और आप तारीख भूल जाएँगे। if true को auth-scoped rule से replace करें, time-bounded से नहीं।

क्या होगा यदि मेरी app वास्तव में public-read (blog, product catalog) है?

तो स्पष्ट रूप से allow read: if true; allow write: if false; केवल public collection पर लिखें — अपने database के हर collection पर नहीं। प्रति collection एक अलग match clause का उपयोग करें और writable rules पर कभी recursive {document=**} wildcard का उपयोग न करें।

अगले कदम

अपने production URL के विरुद्ध एक FixVibe scan चलाएँ — baas.firebase-rules check confirm करता है कि if true वर्तमान में public इंटरनेट से exploitable है या नहीं। Scanner mechanics और Realtime Database और Storage के लिए समानांतर detections के लिए, Firebase rules scanner देखें। Supabase पर misconfiguration की समकक्ष class के लिए, Supabase RLS scanner पढ़ें।