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

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

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

अपने नियमों को एक्सेस और अपडेट करने के लिए, फायरबेस सुरक्षा नियम प्रबंधित और परिनियोजित करें में बताए गए चरणों का पालन करें।

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

जब आप फायरबेस कंसोल में एक डेटाबेस या स्टोरेज इंस्टेंस बनाते हैं, तो आप चुनते हैं कि आपके फायरबेस सुरक्षा नियम आपके डेटा ( लॉक मोड ) तक पहुंच को प्रतिबंधित करते हैं या किसी को एक्सेस करने की अनुमति देते हैं ( टेस्ट मोड )। Cloud Firestore और Realtime Database में, लॉक्ड मोड के लिए डिफ़ॉल्ट नियम सभी उपयोगकर्ताओं तक पहुंच को अस्वीकार करते हैं। क्लाउड स्टोरेज में, केवल प्रमाणित उपयोगकर्ता ही स्टोरेज बकेट तक पहुंच सकते हैं।

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 request.auth != null;
    }
  }
}

विकास-पर्यावरण नियम

जब आप अपने ऐप पर काम कर रहे हों, तो हो सकता है कि आप अपने डेटा तक अपेक्षाकृत खुली या अबाध पहुंच चाहते हों। अपने ऐप को उत्पादन में परिनियोजित करने से पहले बस अपने नियमों को अपडेट करना सुनिश्चित करें। यह भी याद रखें कि यदि आप अपना ऐप परिनियोजित करते हैं, तो यह सार्वजनिक रूप से एक्सेस करने योग्य है — भले ही आपने इसे लॉन्च न किया हो।

याद रखें कि फायरबेस ग्राहकों को आपके डेटा तक सीधी पहुंच की अनुमति देता है, और फायरबेस सुरक्षा नियम दुर्भावनापूर्ण उपयोगकर्ताओं के लिए एकमात्र सुरक्षा अवरोधक हैं। उत्पाद तर्क से अलग नियमों को परिभाषित करने के कई फायदे हैं: ग्राहक सुरक्षा लागू करने के लिए ज़िम्मेदार नहीं हैं, बग्गी कार्यान्वयन आपके डेटा से समझौता नहीं करेगा, और सबसे महत्वपूर्ण बात यह है कि आप दुनिया से डेटा की सुरक्षा के लिए मध्यस्थ सर्वर पर निर्भर नहीं हैं।

सभी प्रमाणित उपयोगकर्ता

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

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

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

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

उत्पादन-तैयार नियम

जैसा कि आप अपने ऐप को परिनियोजित करने के लिए तैयार करते हैं, सुनिश्चित करें कि आपका डेटा सुरक्षित है और आपके उपयोगकर्ताओं को एक्सेस ठीक से प्रदान किया गया है। उपयोगकर्ता-आधारित पहुँच स्थापित करने और डेटा-आधारित पहुँच स्थापित करने के लिए सीधे अपने डेटाबेस से पढ़ने के लिए उत्तोलन प्रमाणीकरण ।

अपने डेटा की संरचना करते समय नियम लिखने पर विचार करें, क्योंकि जिस तरह से आप अपने नियम सेट अप करते हैं, वह प्रभावित करता है कि आप विभिन्न रास्तों पर डेटा तक पहुंच को कैसे प्रतिबंधित करते हैं।

सामग्री-स्वामी केवल पहुंच

ये नियम केवल सामग्री के प्रमाणित स्वामी तक पहुंच को प्रतिबंधित करते हैं। डेटा केवल एक उपयोगकर्ता द्वारा पढ़ने योग्य और लिखने योग्य है, और डेटा पथ में उपयोगकर्ता की आईडी होती है।

जब यह नियम काम करता है: यह नियम अच्छी तरह से काम करता है यदि उपयोगकर्ता द्वारा डेटा को साइल किया जाता है - यदि डेटा तक पहुंचने वाला एकमात्र उपयोगकर्ता वही उपयोगकर्ता है जिसने डेटा बनाया है।

जब यह नियम काम नहीं करता है: यह नियम सेट काम नहीं करता है जब एकाधिक उपयोगकर्ताओं को एक ही डेटा लिखने या पढ़ने की आवश्यकता होती है - उपयोगकर्ता डेटा को अधिलेखित कर देंगे या वे अपने द्वारा बनाए गए डेटा तक पहुंचने में असमर्थ होंगे।

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{documents=**} {
      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>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      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 read: if true
      allow create: if request.auth.uid == request.resource.data.author_uid;
      allow update, 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>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

विशेषता-आधारित और भूमिका-आधारित पहुँच

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

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

जब यह नियम काम नहीं करता है: रीयलटाइम डेटाबेस और क्लाउड स्टोरेज में, आपके नियम उस get() विधि का लाभ नहीं उठा सकते हैं जिसे Cloud Firestore नियम शामिल कर सकते हैं। नतीजतन, आपको अपने नियमों में उपयोग की जा रही विशेषताओं को दर्शाने के लिए अपने डेटाबेस या फ़ाइल मेटाडेटा की संरचना करनी होगी।

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

आप प्रमाणीकरण में कस्टम दावे भी सेट अप कर सकते हैं और फिर उस जानकारी को किसी भी Firebase सुरक्षा नियम में 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
      }
    }
  }
}

कस्टम-दावा विशेषताएँ और भूमिकाएँ

इन नियमों को लागू करने के लिए, फायरबेस ऑथेंटिकेशन में कस्टम क्लेम सेट अप करें और फिर अपने नियमों में क्लेम का लाभ उठाएं।

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin 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 leverage
        ".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 क्लाउड आइडेंटिटी प्लैटफ़ॉर्म (जीसीआईपी) में मल्टीटेनेंसी सेट अप करें और फिर अपने नियमों में टेनेंट का लाभ उठाएं. निम्नलिखित उदाहरण एक विशिष्ट किरायेदार जैसे कि 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;
  }
}