Join us in person and online for Firebase Summit on October 18, 2022. Learn how Firebase can help you accelerate app development, release your app with confidence, and scale with ease. Register now

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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

क्लाउड फायरस्टोर

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

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

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

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

ये नियम केवल Cloud Firestore और Realtime Database में काम करते हैं।

क्लाउड फायरस्टोर

याद रखें कि जब भी आपके नियमों में कोई पठन शामिल होता है, तो नीचे दिए गए नियमों की तरह, आपको Cloud Firestore में पढ़ने की कार्रवाई के लिए बिल भेजा जाता है।

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 क्लाउड आइडेंटिटी प्लेटफ़ॉर्म (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;
  }
}