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

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

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

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

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

Firebase कंसोल में डेटाबेस या स्टोरेज इंस्टेंस बनाते समय, यह चुना जाता है कि Firebase के सुरक्षा नियम, आपके डेटा के ऐक्सेस को प्रतिबंधित करें (लॉक किया गया मोड) या सभी को ऐक्सेस करने की अनुमति दें (टेस्ट मोड).FirebaseFirebase 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;
    }
  }
}

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

ऐप्लिकेशन पर काम करते समय, हो सकता है कि आपको अपने डेटा का ऐक्सेस अपेक्षाकृत ज़्यादा खुला या बिना किसी पाबंदी के चाहिए. पक्का करें कि ऐप्लिकेशन को प्रोडक्शन में डिप्लॉय करने से पहले, Security 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 और फिर auth.token वैरिएबल से वह जानकारी वापस पाई जा सकती है. किसी भी Firebase Security Rules में.

डेटा से तय किए गए एट्रिब्यूट और रोल

ये नियम, सिर्फ़ 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;
  }
}