इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

Firebase Security Rules में आम तौर पर जोखिम की आशंकाओं को समझने के लिए, इस गाइड का इस्तेमाल करें कॉन्फ़िगरेशन, समीक्षा, और अपने नियमों को बेहतर ढंग से सुरक्षित करने, और बदलावों को लागू करने से पहले उनकी जांच करें.

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

अपने Firebase Security Rules को ऐक्सेस करें

अपना मौजूदा Rules देखने के लिए, Firebase सीएलआई या फिर Firebase कंसोल. पक्का करें कि आप एक ही तरीके का इस्तेमाल करके अपने नियमों में बदलाव करें, गलती से अपडेट को ओवरराइट करने से बचने के लिए. अगर आपको पक्के तौर पर नहीं पता है, तो चाहे आपके स्थानीय तौर पर तय किए गए नियम सबसे हाल के अपडेट दिखाते हों, Firebase कंसोल हमेशा आपके Firebase Security Rules का सबसे हाल ही में डिप्लॉय किया गया वर्शन दिखाता है.

Firebase कंसोल से अपने नियमों को ऐक्सेस करने के लिए, अपना प्रोजेक्ट चुनें. इसके बाद, Realtime Database, Cloud Firestore या स्टोरेज पर जाएं. जब आप सही डेटाबेस या स्टोरेज में हों, तो नियम पर क्लिक करें बकेट.

Firebase सीएलआई से अपने नियमों को ऐक्सेस करने के लिए, firebase.json फ़ाइल में बताई गई नियम फ़ाइल पर जाएं.

Firebase Security Rules के बारे में जानें

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

ऐप्लिकेशन डेवलप करने और नियमों के लिए अलग-अलग कॉन्फ़िगरेशन की जांच करते समय, अपने ऐप्लिकेशन को किसी लोकल डेवलपमेंट एनवायरमेंट में चलाने के लिए, लोकल Firebase एमुलेटर में से किसी एक का इस्तेमाल करें.

असुरक्षित नियमों वाली सामान्य स्थितियां

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

ओपन ऐक्सेस

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

इसका सुझाव नहीं दिया जाता: इनके लिए पढ़ने और लिखने का ऐक्सेस सभी उपयोगकर्ता.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

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

समाधान: ऐसे नियम जो पढ़ने पर पाबंदी लगाते हैं और लिखने का ऐक्सेस.

ऐसे नियम बनाएं जो आपकी डेटा हैरारकी के हिसाब से सही हों. सामान्य समाधानों में से एक हम सुरक्षा को ध्यान में रखते हुए, Firebase Authentication के साथ उपयोगकर्ता पर आधारित सुरक्षा का इस्तेमाल करते हैं. ज़्यादा जानें नियमों की मदद से उपयोगकर्ताओं की पुष्टि करने के बारे में जानकारी.

Cloud Firestore

सिर्फ़ कॉन्टेंट के मालिक के लिए

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

Realtime Database

सिर्फ़ कॉन्टेंट के मालिक के लिए

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

Cloud Storage

सिर्फ़ कॉन्टेंट के मालिक के लिए

// 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 यह जांच करता है कि उपयोगकर्ता लॉग इन है या नहीं, लेकिन पुष्टि करने के आधार पर ऐक्सेस पर पाबंदी नहीं लगाता. अगर आपके किसी नियम में शामिल है auth != null, पुष्टि करें कि आपको जिस उपयोगकर्ता ने लॉग-इन किया हुआ है उसे डेटा शामिल है.

इसका सुझाव नहीं दिया जाता: लॉग इन करने वाले किसी भी उपयोगकर्ता के पास आपके पूरे डेटाबेस को पढ़ने और उसमें बदलाव करने का ऐक्सेस होता है.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

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

समाधान: सुरक्षा का इस्तेमाल करके ऐक्सेस को सीमित करें शर्तें.

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

Cloud Firestore

भूमिका के हिसाब से ऐक्सेस

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

Realtime Database

सिर्फ़ कॉन्टेंट का मालिक

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

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

सिर्फ़ कॉन्टेंट के मालिक के लिए

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

(Realtime Database) गलत तरीके से इनहेरिट किए गए नियम

Realtime Database Security Rules कैस्केड, जिसमें नियम ज़्यादा उथले हैं और पैरंट पाथ बदल रहे हैं चाइल्ड नोड में नियम बनाते हैं. चाइल्ड नोड पर नियम लिखते समय, याद रखें उपयोगकर्ताओं को सिर्फ़ कुछ और खास अधिकार मिल सकते हैं. अपने डेटाबेस के किसी गहरे पाथ में मौजूद डेटा के ऐक्सेस को बेहतर नहीं बनाया जा सकता या उसे रद्द नहीं किया जा सकता.

इसका सुझाव नहीं दिया जाता: चाइल्ड पाथ पर नियमों को बेहतर बनाना

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

समाधान: पैरंट पाथ पर नियम लिखें जो काफ़ी बड़े हैं और चाइल्ड पाथ पर ज़्यादा खास अधिकार देते हैं अगर डेटा ऐक्सेस करने के लिए आपको ज़्यादा बारीकी से जानकारी देनी है, तो अपने नियमों में ज़्यादा जानकारी का इस्तेमाल करें. Realtime Database Security Rules के कोर सिंटैक्स में, कैस्केडिंग Realtime Database Security Rules के बारे में ज़्यादा जानें.

बंद ऐक्सेस

अपना ऐप्लिकेशन डेवलप करते समय, एक और सामान्य तरीका यह है कि अपने डेटा लॉक किया गया. आम तौर पर, इसका मतलब है कि आपने 'रीड ऐंड राइट' सुविधा बंद कर दी है सभी लोगों को इसकी जानकारी दी जाएगी:

Cloud Firestore

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

Realtime Database

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

Cloud Storage

// 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 एडमिन SDK टूल और Cloud Functions, अब भी आपकी डेटाबेस. Cloud Firestore का इस्तेमाल करने के लिए, इन नियमों का इस्तेमाल करें या Realtime Database सिर्फ़ सर्वर के तौर पर Firebase के साथ बैकएंड के साथ काम करता है एडमिन SDK टूल. हालांकि यह सुरक्षित है, लेकिन आपको यह टेस्ट करना चाहिए कि आपके ऐप्लिकेशन के क्लाइंट वे डेटा को सही तरीके से वापस पा सकें.

Cloud Firestore Security Rules और इनके काम करने के तरीके के बारे में ज़्यादा जानें Cloud Firestore Security Rules का इस्तेमाल शुरू करें.

अपने Cloud Firestore Security Rules की जांच करना

अपने ऐप्लिकेशन के काम करने के तरीके के बारे में जानने और अपने Cloud Firestore Security Rules कॉन्फ़िगरेशन की पुष्टि करने के लिए, Firebase एम्युलेटर का इस्तेमाल करें. Cloud Firestore का इस्तेमाल करना डिप्लॉय करने से पहले, लोकल एनवायरमेंट में यूनिट टेस्ट को चलाने और उन्हें ऑटोमेट करने के लिए एम्युलेटर कोई भी बदलाव.

Firebase कंसोल में Firebase Security Rules की तुरंत पुष्टि करने के लिए इसका इस्तेमाल करें Firebase रूल्स सिम्युलेटर.