असुरक्षित नियमों को ठीक करें

इस गाइड की मदद से, Cloud Firestore Security Rules कॉन्फ़िगरेशन में मौजूद सामान्य कमज़ोरियों के बारे में जानें. साथ ही, अपने नियमों की समीक्षा करें और उन्हें बेहतर तरीके से सुरक्षित करें. इसके अलावा, नियमों में किए गए बदलावों को डिप्लॉय करने से पहले, उनकी जांच करें.

अगर आपको यह सूचना मिलती है कि आपका Cloud Firestore डेटाबेस सुरक्षित नहीं है, तो सुरक्षा नियमों में बदलाव करके और उनकी जांच करके, कमज़ोरियों को ठीक किया जा सकता है Cloud Firestore Security Rules.

मौजूदा सुरक्षा नियम देखने के लिए, Firebase कंसोल में नियम टैब पर जाएं.

अपने Cloud Firestore Security Rules के बारे में जानकारी

Cloud Firestore Security Rules आपके डेटा को नुकसान पहुंचाने वाले उपयोगकर्ताओं से सुरक्षित रखते हैं. Firebase कंसोल में बनाए गए किसी भी Cloud Firestore इंस्टेंस के लिए डिफ़ॉल्ट नियम, सभी उपयोगकर्ताओं को ऐक्सेस करने से रोकते हैं. अपने ऐप्लिकेशन को डेवलप करने और डेटाबेस को ऐक्सेस करने के लिए, आपको उन नियमों में बदलाव करना होगा. साथ ही, डेवलपमेंट एनवायरमेंट में सभी उपयोगकर्ताओं को ऐक्सेस की अनुमति दी जा सकती है. हालांकि, अपने ऐप्लिकेशन को प्रोडक्शन एनवायरमेंट में डिप्लॉय करने से पहले, नियमों को सही तरीके से कॉन्फ़िगर करें और अपने डेटा को सुरक्षित करें.

अपने ऐप्लिकेशन को डेवलप करते समय और नियमों के लिए अलग-अलग कॉन्फ़िगरेशन की जांच करते समय, Cloud Firestore एम्युलेटर का इस्तेमाल करके, अपने ऐप्लिकेशन को लोकल डेवलपमेंट एनवायरमेंट में चलाएं.

सुरक्षा के लिहाज़ से कमज़ोर नियमों से जुड़ी सामान्य समस्याएं

Cloud Firestore Security Rules की समीक्षा करें और उन्हें अपडेट करें. ये नियम, डिफ़ॉल्ट रूप से सेट अप किए जा सकते हैं या Cloud Firestore की मदद से अपने ऐप्लिकेशन को डेवलप करते समय सेट अप किए जा सकते हैं. अपने ऐप्लिकेशन को डिप्लॉय करने से पहले, इन नियमों की समीक्षा और अपडेट करना ज़रूरी है. यहां बताई गई सामान्य गलतियों से बचकर, पक्का करें कि आपने अपने उपयोगकर्ताओं के डेटा को सही तरीके से सुरक्षित किया हो.

ओपन ऐक्सेस

Cloud Firestore सेट अप करते समय, आपने डेवलपमेंट के दौरान ओपन ऐक्सेस की अनुमति देने के लिए, अपने नियम सेट किए होंगे. आपको लग सकता है कि आपका ऐप्लिकेशन सिर्फ़ आप इस्तेमाल कर रहे हैं. हालांकि, अगर आपने इसे डिप्लॉय किया है, तो यह इंटरनेट पर उपलब्ध है. अगर उपयोगकर्ताओं की पुष्टि नहीं की जा रही है और सुरक्षा नियमों को कॉन्फ़िगर नहीं किया जा रहा है, तो कोई भी व्यक्ति आपके प्रोजेक्ट आईडी का अनुमान लगाकर, डेटा चुरा सकता है, उसमें बदलाव कर सकता है या उसे मिटा सकता है.

सुझाव नहीं दिया जाता: सभी उपयोगकर्ताओं को पढ़ने और लिखने का ऐक्सेस देना.
// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}
समाधान: ऐसे नियम सेट करें जिनसे पढ़ने और लिखने के ऐक्सेस को सीमित किया जा सके.

ऐसे नियम बनाएं जो आपके डेटा के क्रम के हिसाब से सही हों. सुरक्षा के लिहाज़ से कमज़ोर नियमों से जुड़ी इस समस्या को हल करने का एक सामान्य तरीका है कि Firebase Authentication की मदद से, उपयोगकर्ता के हिसाब से सुरक्षा सेट की जाए. नियमों की मदद से, उपयोगकर्ताओं की पुष्टि करने के बारे में ज़्यादा जानें .

सिर्फ़ कॉन्टेंट का मालिक

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;

    }
  }
}
  

पब्लिक और प्राइवेट ऐक्सेस का मिला-जुला इस्तेमाल

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}
  

पुष्टि किए गए किसी भी उपयोगकर्ता को ऐक्सेस की अनुमति देना

कभी-कभी, Cloud Firestore Security Rules यह जांचते हैं कि कोई उपयोगकर्ता लॉग इन है या नहीं. हालांकि, ये नियम, पुष्टि के आधार पर ऐक्सेस को सीमित नहीं करते. अगर आपके किसी नियम में auth != null शामिल है, तो पुष्टि करें कि आपको लॉग-इन किए गए किसी भी उपयोगकर्ता को डेटा का ऐक्सेस देना है.

सुझाव नहीं दिया जाता: लॉग-इन किए गए किसी भी उपयोगकर्ता को, पूरे डेटाबेस को पढ़ने और लिखने का ऐक्सेस देना.
service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}
समाधान: सुरक्षा की शर्तों का इस्तेमाल करके, ऐक्सेस को सीमित करना.

पुष्टि की जांच करते समय, पुष्टि करने की किसी प्रॉपर्टी का इस्तेमाल करके, खास डेटा सेट के लिए खास उपयोगकर्ताओं के ऐक्सेस को सीमित किया जा सकता है. सुरक्षा की शर्तें जोड़ने और रोल के आधार पर ऐक्सेस देने के बारे में ज़्यादा जानें.

रोल के आधार पर ऐक्सेस

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    match /some_collection/{document} {
     allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

एट्रिब्यूट के आधार पर ऐक्सेस

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}
  

पब्लिक और प्राइवेट ऐक्सेस का मिला-जुला इस्तेमाल

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

पुष्टि नहीं किए गए ईमेल पतों को ऐक्सेस की अनुमति देना

कभी-कभी, Cloud Firestore Security Rules यह जांचते हैं कि किसी उपयोगकर्ता का ईमेल, किसी खास डोमेन से जुड़ा है या नहीं. आम तौर पर, यह एक अच्छी प्रैक्टिस है. हालांकि, साइन-इन के दौरान ईमेल की पुष्टि हमेशा नहीं की जाती. ऐसा तब तक होता है, जब तक उपयोगकर्ता, पुष्टि करने वाला ईमेल मिलने पर कोई अतिरिक्त चरण पूरा नहीं करता. पक्का करें कि आपने इस बात की पुष्टि की हो कि ईमेल, उपयोगकर्ता का ही है.

सुझाव नहीं दिया जाता: कोई भी उपयोगकर्ता, किसी भी ईमेल पते से साइन इन कर सकता है.
service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email.endsWith('@example.com')
    }
  }
}
समाधान: सिर्फ़ पुष्टि किए गए ईमेल को ऐक्सेस की अनुमति देना.

ईमेल की पुष्टि करना

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email_verified
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

ऐक्सेस बंद करना

अपने ऐप्लिकेशन को डेवलप करते समय, डेटा को लॉक रखना एक और सामान्य तरीका है. आम तौर पर, इसका मतलब है कि आपने सभी उपयोगकर्ताओं के लिए, पढ़ने और लिखने के ऐक्सेस को बंद कर दिया है. जैसे:

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Firebase Admin SDK और Cloud Functions अब भी आपके डेटाबेस को ऐक्सेस कर सकते हैं. इन नियमों का इस्तेमाल तब करें, जब आपको Cloud Firestore को सिर्फ़ सर्वर-साइड बैकएंड के तौर पर, Firebase Admin SDK के साथ इस्तेमाल करना हो. यह सुरक्षित है. हालांकि, आपको यह जांच करनी चाहिए कि आपके ऐप्लिकेशन के क्लाइंट, डेटा को सही तरीके से वापस पा सकते हैं या नहीं.

Cloud Firestore Security Rules और उनके काम करने के तरीके के बारे में ज़्यादा जानने के लिए, Cloud Firestore Security Rules लेख पढ़ें.

अपने Cloud Firestore Security Rules की जांच करें

अपने ऐप्लिकेशन के व्यवहार की जांच करने और अपनी Cloud Firestore Security Rules कॉन्फ़िगरेशन की पुष्टि करने के लिए, Cloud Firestore एम्युलेटर का इस्तेमाल करें. एम्युलेटर का इस्तेमाल करके, किसी भी बदलाव को डिप्लॉय करने से पहले, लोकल एनवायरमेंट में यूनिट टेस्ट चलाएं और उन्हें ऑटोमेट करें.Cloud Firestore

Firebase कंसोल में, अपडेट किए गए Cloud Firestore Security Rules की तुरंत जांच करने के लिए, Rules Playground टूल का इस्तेमाल करें.

  1. Rules Playground खोलने के लिए, Rules Playground पर क्लिक करें, जो नियम टैब में है.
  2. Rules Playground की सेटिंग में, अपनी जांच के लिए विकल्प चुनें. इनमें ये शामिल हैं:
    • पढ़ने या लिखने की जांच करना
    • आपके डेटाबेस में कोई खास जगह, जिसे पाथ के तौर पर दिखाया जाता है
    • पुष्टि करने का तरीका — पुष्टि नहीं की गई, पुष्टि की गई, गुमनाम उपयोगकर्ता या कोई खास उपयोगकर्ता आईडी
    • दस्तावेज़ से जुड़ा वह डेटा जिसे आपके नियम खास तौर पर रेफ़र करते हैं. उदाहरण के लिए, अगर आपके नियमों के मुताबिक, लिखने की अनुमति देने से पहले किसी खास फ़ील्ड का होना ज़रूरी है
  3. चलाएं पर क्लिक करें और नियमों वाली विंडो के ऊपर मौजूद बैनर में नतीजे देखें.