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

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

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

अपने नियमों तक पहुंचने और अद्यतन करने के लिए, फायरबेस सुरक्षा नियम प्रबंधित और तैनात करें में उल्लिखित चरणों का पालन करें।

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

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

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() विधि का लाभ नहीं उठा सकते हैं जिसे क्लाउड फायरस्टोर नियम शामिल कर सकते हैं। नतीजतन, आपको अपने नियमों में उपयोग की जा रही विशेषताओं को प्रतिबिंबित करने के लिए अपने डेटाबेस या फ़ाइल मेटाडेटा की संरचना करनी होगी।

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

आप प्रमाणीकरण में कस्टम दावे भी सेट कर सकते हैं और फिर किसी भी फायरबेस सुरक्षा नियमों में auth.token वैरिएबल से उस जानकारी को पुनः प्राप्त कर सकते हैं।

डेटा-परिभाषित विशेषताएँ और भूमिकाएँ

ये नियम केवल क्लाउड फायरस्टोर और रियलटाइम डेटाबेस में काम करते हैं।

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