অনিরাপদ নিয়ম এড়িয়ে চলুন

Firebase Security Rules কনফিগারেশনের সাধারণ দুর্বলতাগুলি বুঝতে, আপনার নিজের নিয়মগুলি পর্যালোচনা এবং আরও ভালভাবে সুরক্ষিত করতে এবং সেগুলি স্থাপন করার আগে আপনার পরিবর্তনগুলি পরীক্ষা করতে এই নির্দেশিকাটি ব্যবহার করুন৷

যদি আপনি একটি সতর্কতা পান যে আপনার ডেটা সঠিকভাবে সুরক্ষিত নয়, এই সাধারণভাবে করা ত্রুটিগুলি পর্যালোচনা করুন এবং যেকোনো দুর্বল নিয়ম আপডেট করুন৷

আপনার Firebase Security Rules অ্যাক্সেস করুন

আপনার বিদ্যমান Rules দেখতে, হয় Firebase CLI বা Firebase কনসোল ব্যবহার করুন৷ নিশ্চিত করুন যে আপনি একই পদ্ধতি ব্যবহার করে আপনার নিয়মগুলি সম্পাদনা করেছেন, ধারাবাহিকভাবে, আপডেটগুলিকে ভুলভাবে ওভাররাইট করা এড়াতে। আপনি যদি নিশ্চিত না হন যে আপনার স্থানীয়ভাবে সংজ্ঞায়িত নিয়মগুলি সাম্প্রতিকতম আপডেটগুলিকে প্রতিফলিত করে কিনা, Firebase কনসোল সর্বদা আপনার Firebase Security Rules সাম্প্রতিকতম স্থাপন করা সংস্করণ দেখায়৷

Firebase কনসোল থেকে আপনার নিয়মগুলি অ্যাক্সেস করতে, আপনার প্রকল্প নির্বাচন করুন, তারপরে Realtime Database , Cloud Firestore বা স্টোরেজে নেভিগেট করুন। আপনি সঠিক ডাটাবেস বা স্টোরেজ বালতিতে গেলে নিয়মগুলিতে ক্লিক করুন।

Firebase CLI থেকে আপনার নিয়মগুলি অ্যাক্সেস করতে, আপনার firebase.json ফাইলে উল্লেখিত নিয়ম ফাইলে যান।

Firebase Security Rules বুঝুন

Firebase Security Rules দূষিত ব্যবহারকারীদের থেকে আপনার ডেটা রক্ষা করে। আপনি যখন Firebase কনসোলে একটি ডাটাবেস ইনস্ট্যান্স বা Cloud Storage বালতি তৈরি করেন, আপনি হয় সমস্ত ব্যবহারকারীর অ্যাক্সেস অস্বীকার করতে পারেন ( লকড মোড ) বা সমস্ত ব্যবহারকারীকে অ্যাক্সেস দিতে পারেন ( টেস্ট মোড )৷ যদিও আপনি বিকাশের সময় আরও খোলা কনফিগারেশন চান, আপনার অ্যাপ স্থাপন করার আগে আপনার নিয়মগুলি সঠিকভাবে কনফিগার করতে এবং আপনার ডেটা সুরক্ষিত করতে সময় নিচ্ছেন তা নিশ্চিত করুন।

আপনি যখন আপনার অ্যাপটি তৈরি করছেন এবং আপনার নিয়মের জন্য বিভিন্ন কনফিগারেশন পরীক্ষা করছেন, স্থানীয় উন্নয়ন পরিবেশে আপনার অ্যাপ চালানোর জন্য স্থানীয় ফায়ারবেস এমুলেটরগুলির একটি ব্যবহার করুন।

অনিরাপদ নিয়ম সহ সাধারণ পরিস্থিতি

আপনি যে Rules ডিফল্টরূপে সেট আপ করে থাকতে পারেন বা আপনি প্রাথমিকভাবে আপনার অ্যাপটি তৈরি করার জন্য কাজ করেছিলেন তা আপনার অ্যাপ স্থাপন করার আগে পর্যালোচনা করা উচিত এবং আপডেট করা উচিত। নিশ্চিত করুন যে আপনি নিম্নলিখিত সাধারণ সমস্যাগুলি এড়িয়ে আপনার ব্যবহারকারীদের ডেটা সঠিকভাবে সুরক্ষিত করেছেন৷

খোলা অ্যাক্সেস

আপনি আপনার Firebase প্রকল্প সেট আপ করার সময়, আপনি বিকাশের সময় খোলা অ্যাক্সেসের অনুমতি দেওয়ার জন্য আপনার নিয়মগুলি সেট করতে পারেন। আপনি ভাবতে পারেন যে আপনিই একমাত্র ব্যক্তি যিনি আপনার অ্যাপ ব্যবহার করছেন, কিন্তু আপনি যদি এটি ব্যবহার করে থাকেন তবে এটি ইন্টারনেটে উপলব্ধ। আপনি যদি ব্যবহারকারীদের প্রমাণীকরণ না করেন এবং নিরাপত্তা বিধি কনফিগার না করেন, তাহলে যে কেউ আপনার প্রকল্প আইডি অনুমান করে সে ডেটা চুরি, পরিবর্তন বা মুছে ফেলতে পারে।

প্রস্তাবিত নয়: সমস্ত ব্যবহারকারীর জন্য পড়ার এবং লেখার অ্যাক্সেস।
// 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 using 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 সাথে ব্যবহারকারী-ভিত্তিক নিরাপত্তা। নিয়ম সহ ব্যবহারকারীদের প্রমাণীকরণ সম্পর্কে আরও জানুন।

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == 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 public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == 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>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}
  

কোনো প্রমাণীকৃত ব্যবহারকারীর জন্য অ্যাক্সেস

কখনও কখনও, Rules পরীক্ষা করে যে কোনও ব্যবহারকারী লগ ইন করেছেন, কিন্তু সেই প্রমাণীকরণের উপর ভিত্তি করে অ্যাক্সেসকে আরও সীমাবদ্ধ করবেন না। যদি আপনার নিয়মগুলির মধ্যে একটিতে 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 "administrator" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_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 `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>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      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 সম্পর্কে আরও জানুন৷

বন্ধ অ্যাক্সেস

আপনি যখন আপনার অ্যাপটি তৈরি করছেন, তখন আরেকটি সাধারণ পদ্ধতি হল আপনার ডেটা লক ডাউন রাখা। সাধারণত, এর মানে হল যে আপনি সমস্ত ব্যবহারকারীর পড়ার এবং লেখার অ্যাক্সেস বন্ধ করে দিয়েছেন, নিম্নরূপ:

// 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 অ্যাডমিন SDK এবং ক্লাউড ফাংশন এখনও আপনার ডাটাবেস অ্যাক্সেস করতে পারে। আপনি যখন Firebase অ্যাডমিন SDK-এর সাথে একত্রে Cloud Firestore বা Realtime Database শুধুমাত্র সার্ভার-ব্যাকএন্ড হিসাবে ব্যবহার করতে চান তখন এই নিয়মগুলি ব্যবহার করুন৷ এটি সুরক্ষিত থাকাকালীন, আপনার পরীক্ষা করা উচিত যে আপনার অ্যাপের ক্লায়েন্টরা সঠিকভাবে ডেটা পুনরুদ্ধার করতে পারে।

Cloud Firestore Security Rules সম্পর্কে আরও জানুন এবং Cloud Firestore Security Rules সাথে শুরু করুন এ কীভাবে তারা কাজ করে।

আপনার Cloud Firestore Security Rules পরীক্ষা করুন

আপনার অ্যাপের আচরণ পরীক্ষা করতে এবং আপনার Cloud Firestore Security Rules কনফিগারেশন যাচাই করতে, ফায়ারবেস এমুলেটর ব্যবহার করুন। আপনি কোনো পরিবর্তন স্থাপন করার আগে স্থানীয় পরিবেশে ইউনিট পরীক্ষা চালানো এবং স্বয়ংক্রিয় করতে Cloud Firestore এমুলেটর ব্যবহার করুন।

Firebase কনসোলে Firebase Security Rules দ্রুত যাচাই করতে, ফায়ারবেস নিয়ম সিমুলেটর ব্যবহার করুন।