असुरक्षित नियमों से बचें

Firebase सुरक्षा नियम कॉन्फ़िगरेशन में सामान्य भेद्यताओं को समझने के लिए इस मार्गदर्शिका का उपयोग करें, अपने स्वयं के नियमों की समीक्षा करें और उन्हें बेहतर ढंग से सुरक्षित करें, और उन्हें परिनियोजित करने से पहले अपने परिवर्तनों का परीक्षण करें।

यदि आपको यह अलर्ट प्राप्त होता है कि आपका डेटा उचित रूप से सुरक्षित नहीं है, तो सामान्य रूप से की गई इन त्रुटियों की समीक्षा करें और किसी भी असुरक्षित नियम को अपडेट करें।

अपने फायरबेस सुरक्षा नियमों तक पहुंचें

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

Firebase कंसोल से अपने नियमों तक पहुंचने के लिए, अपना प्रोजेक्ट चुनें, फिर Realtime Database , Cloud Firestore या Storage पर नेविगेट करें। सही डेटाबेस या स्टोरेज बकेट में पहुंचने के बाद नियम पर क्लिक करें।

Firebase CLI से अपने नियमों तक पहुँचने के लिए, अपनी firebase.json फ़ाइल में नोट की गई नियम फ़ाइल पर जाएँ।

फायरबेस सुरक्षा नियमों को समझें

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

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

असुरक्षित नियमों के साथ सामान्य परिदृश्य

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

खुला एक्सेस

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

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this ruleset in production; it allows
// anyone to overwrite your entire database.

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

{
  // Allow read/write access to all users under any conditions
  // Warning: **NEVER** use this ruleset in production; it allows
  // anyone to overwrite your entire database.

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

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with App Engine, this will also make
// files uploaded via App Engine public.
// Warning: This rule makes every file in your Cloud Storage bucket accessible to any user.
// Apply caution before using it in production, since it means anyone
// can overwrite all your files.

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

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

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 write: if request.auth != null && request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

{
  "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"
      }
    }
  }
}
    

{
  // 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"
    }
  }
}
    

// 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.uid == userId;
    }
  }
}

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

किसी भी प्रमाणित उपयोगकर्ता के लिए पहुँच

कभी-कभी, नियम जाँचते हैं कि उपयोगकर्ता लॉग इन है, लेकिन उस प्रमाणीकरण के आधार पर पहुँच को और प्रतिबंधित नहीं करते हैं। यदि आपके नियमों में से एक में auth != null शामिल है, तो पुष्टि करें कि आप चाहते हैं कि कोई लॉग-इन उपयोगकर्ता डेटा तक पहुंच प्राप्त करे।

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

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

// Only authenticated users can read or write to the bucket
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    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"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}
  

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 write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

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

{
  "rules": {
    "some_path/$uid": {
      ".write": "auth.uid === $uid",
      // Create a "public" subpath in your dataset
      "public": {
        ".read": true
        // or ".read": "auth.uid !== null"
      },
      // Create a "private" subpath in your dataset
      "private": {
        ".read": "auth.uid === $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"
    }
  }
}
    

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

// 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.uid == userId;
    }
  }
}

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

(रीयलटाइम डेटाबेस) अनुचित तरीके से विरासत में मिले नियम

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

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

बंद पहुंच

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

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

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

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

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

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

क्लाउड फायरस्टोर सुरक्षा नियमों के बारे में और जानें कि वे क्लाउड फायरस्टोर सुरक्षा नियमों के साथ आरंभ करें में कैसे काम करते हैं।

अपने क्लाउड फायरस्टोर सुरक्षा नियमों का परीक्षण करें

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

फायरबेस कंसोल में फायरबेस सुरक्षा नियमों को जल्दी से सत्यापित करने के लिए, फायरबेस नियम सिम्युलेटर का उपयोग करें।