सुरक्षा के बुनियादी नियम

Firebase Security Rules की मदद से, सेव किए गए डेटा का ऐक्सेस कंट्रोल किया जा सकता है. नियमों के सिंटैक्स में बदलाव किया जा सकता है. इसका मतलब है कि ऐसे नियम बनाए जा सकते हैं जो किसी भी चीज़ से मेल खाते हों. जैसे, सभी राइट ऑपरेशन, पूरा डेटाबेस या किसी खास दस्तावेज़ पर किए गए ऑपरेशन.

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

अपने नियमों को ऐक्सेस करने और उन्हें अपडेट करने के लिए, Firebase Security Rules को मैनेज करना और डिप्लॉय करना में बताया गया तरीका अपनाएं.

डिफ़ॉल्ट नियम: लॉक मोड

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

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

{
  "rules": {
    ".read": false,
    ".write": false
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

डेवलपमेंट एनवायरमेंट के नियम

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

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

पुष्टि किए गए सभी उपयोगकर्ता

हमारा सुझाव है कि आप अपने डेटा का ऐक्सेस, साइन इन किए हुए किसी भी उपयोगकर्ता को न दें. हालांकि, ऐप्लिकेशन डेवलप करते समय, पुष्टि किए गए किसी भी उपयोगकर्ता को ऐक्सेस देना फ़ायदेमंद हो सकता है.

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}

{
  "rules": {
    "some_path": {
      ".read": "auth.uid !== null",
      ".write": "auth.uid !== null"
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /some_folder/{fileName} {
      allow read, write: if request.auth != null;
    }
  }
}

प्रोडक्शन के लिए तैयार नियम

ऐप्लिकेशन को डिप्लॉय करने से पहले, पक्का करें कि आपका डेटा सुरक्षित हो और उपयोगकर्ताओं को ऐक्सेस देने की प्रोसेस सही तरीके से पूरी की गई हो. उपयोगकर्ता के आधार पर ऐक्सेस सेट अप करने के लिए, Authentication का इस्तेमाल करें. साथ ही, डेटा के आधार पर ऐक्सेस सेट अप करने के लिए, सीधे अपने डेटाबेस से पढ़ें.

अपने डेटा को स्ट्रक्चर करते समय, नियमों को लिखने के बारे में सोचें. ऐसा इसलिए, क्योंकि नियमों को सेट अप करने के तरीके से यह तय होता है कि अलग-अलग पाथ पर डेटा के ऐक्सेस को कैसे सीमित किया जाए.

सिर्फ़ कॉन्टेंट के मालिक के पास ऐक्सेस होता है

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

यह नियम कब काम करता है: यह नियम तब अच्छी तरह से काम करता है, जब डेटा को उपयोगकर्ता के हिसाब से अलग-अलग किया गया हो. इसका मतलब है कि अगर डेटा को ऐक्सेस करने वाला उपयोगकर्ता वही है जिसने डेटा बनाया है.

यह नियम कब काम नहीं करता: यह नियम तब काम नहीं करता, जब कई उपयोगकर्ताओं को एक ही डेटा को लिखना या पढ़ना हो. ऐसे में, उपयोगकर्ता डेटा को बदल देंगे या वे उस डेटा को ऐक्सेस नहीं कर पाएंगे जिसे उन्होंने बनाया है.

इस नियम को सेट अप करने के लिए: ऐसा नियम बनाएं जिससे यह पुष्टि हो सके कि डेटा को पढ़ने या उसमें बदलाव करने का अनुरोध करने वाला उपयोगकर्ता, उस डेटा का मालिक है.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{document} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

सार्वजनिक और निजी, दोनों तरह का ऐक्सेस

इस नियम के तहत, कोई भी व्यक्ति डेटासेट को पढ़ सकता है. हालांकि, किसी पाथ पर डेटा बनाने या उसमें बदलाव करने की सुविधा सिर्फ़ पुष्टि किए गए कॉन्टेंट के मालिक को मिलती है.

यह नियम कब काम करता है: यह नियम उन ऐप्लिकेशन के लिए सबसे सही है जिनमें ऐसे एलिमेंट होते हैं जिन्हें सार्वजनिक तौर पर पढ़ा जा सकता है. हालांकि, इन एलिमेंट के मालिकों के पास ही इनमें बदलाव करने का ऐक्सेस होता है. उदाहरण के लिए, कोई चैट ऐप्लिकेशन या ब्लॉग.

यह नियम कब काम नहीं करता: कॉन्टेंट के मालिक के लिए बने नियम की तरह, यह नियमों का सेट तब काम नहीं करता, जब एक से ज़्यादा उपयोगकर्ताओं को एक ही डेटा में बदलाव करना हो. उपयोगकर्ता एक-दूसरे के डेटा को आखिर में बदल देंगे.

इस नियम को सेट अप करने के लिए: ऐसा नियम बनाएं जो सभी उपयोगकर्ताओं (या पुष्टि किए गए सभी उपयोगकर्ताओं) को पढ़ने का ऐक्सेस दे. साथ ही, यह पुष्टि करे कि डेटा लिखने वाला उपयोगकर्ता ही मालिक है.

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;
    }
  }
}

{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data

  "rules": {
    "some_path": {
      "$uid": {
        ".read": true,
        // or ".read": "auth.uid !== null" for only authenticated users
        ".write": "auth.uid === $uid"
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

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

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

यह नियम कब लागू होता है: अगर उपयोगकर्ताओं को कोई भूमिका असाइन की जा रही है, तो यह नियम आपको भूमिकाओं या उपयोगकर्ताओं के खास ग्रुप के आधार पर ऐक्सेस सीमित करने की सुविधा देता है. उदाहरण के लिए, अगर आपको ग्रेड सेव करने हैं, तो "छात्र-छात्राएं" ग्रुप को ऐक्सेस के अलग-अलग लेवल असाइन किए जा सकते हैं. जैसे, सिर्फ़ कॉन्टेंट पढ़ने का ऐक्सेस. इसी तरह, "शिक्षक" ग्रुप को अपने विषय में कॉन्टेंट पढ़ने और लिखने का ऐक्सेस दिया जा सकता है. साथ ही, "प्रिंसिपल" ग्रुप को सभी कॉन्टेंट पढ़ने का ऐक्सेस दिया जा सकता है.

यह नियम कब काम नहीं करता: Realtime Database और Cloud Storage में, आपके नियम get() तरीके का इस्तेमाल नहीं कर सकते. हालांकि, Cloud Firestore के नियम इस तरीके का इस्तेमाल कर सकते हैं. इसलिए, आपको अपने डेटाबेस या फ़ाइल के मेटाडेटा को इस तरह से स्ट्रक्चर करना होगा कि नियमों में इस्तेमाल किए जा रहे एट्रिब्यूट दिखें.

इस नियम को सेट अप करने के लिए: Cloud Firestore में, अपने उपयोगकर्ताओं के दस्तावेज़ों में ऐसा फ़ील्ड शामिल करें जिसे पढ़ा जा सके. इसके बाद, उस फ़ील्ड को पढ़ने और शर्तों के हिसाब से ऐक्सेस देने के लिए, अपना नियम बनाएं. Realtime Database में, एक ऐसा डेटा पाथ बनाएं जो आपके ऐप्लिकेशन के उपयोगकर्ताओं को तय करता हो और उन्हें चाइल्ड नोड में भूमिका असाइन करता हो.

Authentication में कस्टम दावे भी सेट अप किए जा सकते हैं. इसके बाद, किसी भी Firebase Security Rules में auth.token वैरिएबल से वह जानकारी वापस पाई जा सकती है.

डेटा के हिसाब से तय किए गए एट्रिब्यूट और भूमिकाएं

ये नियम सिर्फ़ Cloud Firestore और Realtime Database में काम करते हैं.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

कस्टम-क्लेम एट्रिब्यूट और भूमिकाएं

इन नियमों को लागू करने के लिए, Firebase Authentication में कस्टम दावे सेट अप करें. इसके बाद, अपने नियमों में इन दावों का इस्तेमाल करें.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an administrator claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to use
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

service firebase.storage {
  // Allow reads if the group ID in your token matches the file metadata's `owner` property
  // Allow writes if the group ID is in the user's custom token
  match /files/{groupId}/{fileName} {
    allow read: if resource.metadata.owner == request.auth.token.groupId;
    allow write: if request.auth.token.groupId == groupId;
  }
}

किरायेदारी से जुड़े एट्रिब्यूट

इन नियमों को लागू करने के लिए, Google Cloud Identity Platform (GCIP) में मल्टीटेंसी सेट अप करें. इसके बाद, अपने नियमों में किरायेदार का इस्तेमाल करें. यहां दिए गए उदाहरणों में, किसी खास किरायेदार के उपयोगकर्ता को लिखने की अनुमति दी गई है. उदाहरण के लिए, tenant2-m6tyz

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}