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 } } }
क्लोज़्ड ऐक्सेस
अपना ऐप्लिकेशन डेवलप करते समय, एक और सामान्य तरीका यह है कि अपने डेटा को लॉक किया रखें. आम तौर पर, इसका मतलब है कि आपने सभी उपयोगकर्ताओं के लिए, पढ़ने और लिखने का ऐक्सेस बंद कर दिया है. इसके लिए, यह तरीका अपनाएं:
// 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 एडमिन SDK टूल और Cloud Functions, अब भी आपके डेटाबेस को ऐक्सेस कर सकते हैं. इन नियमों का इस्तेमाल तब करें, जब आप Firebase एडमिन SDK टूल के साथ Cloud Firestore को सिर्फ़ सर्वर के लिए बैकएंड के तौर पर इस्तेमाल करना चाहें. हालांकि यह सुरक्षित है, लेकिन आपको यह जांचना चाहिए कि आपके ऐप्लिकेशन के क्लाइंट डेटा को सही तरीके से वापस पा सकते हैं या नहीं.
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 टूल का इस्तेमाल करें.
- Rules Playground खोलने के लिए, नियम टैब में जाकर, Rules Playground पर क्लिक करें.
- नियमों के प्लेसग्राउंड की सेटिंग में, अपने टेस्ट के लिए विकल्प चुनें. इनमें ये विकल्प शामिल हैं:
- डेटा पढ़ने या लिखने की जांच करना
- आपके डेटाबेस में मौजूद किसी खास जगह का पाथ
- पुष्टि करने का तरीका — बिना पुष्टि वाला, पुष्टि किया गया ऐसा उपयोगकर्ता जिसकी पहचान छिपाकर कॉन्टेंट ऐक्सेस किया जा रहा है या कोई खास उपयोगकर्ता आईडी
- दस्तावेज़ से जुड़ा ऐसा डेटा जिसका आपके नियमों में खास तौर पर रेफ़रंस दिया गया हो. उदाहरण के लिए, अगर आपके नियमों के मुताबिक, डेटा में बदलाव करने की अनुमति देने से पहले किसी खास फ़ील्ड की मौजूदगी ज़रूरी है
- चालू करें पर क्लिक करें और नियमों की विंडो के ऊपर मौजूद बैनर में नतीजे देखें.