Firebase Security Rules কনফিগারেশনের সাধারণ দুর্বলতাগুলি বুঝতে, আপনার নিজস্ব নিয়মগুলি পর্যালোচনা এবং আরও ভালভাবে সুরক্ষিত করতে এবং সেগুলি স্থাপন করার আগে আপনার পরিবর্তনগুলি পরীক্ষা করতে এই নির্দেশিকাটি ব্যবহার করুন।
যদি আপনি একটি সতর্কতা পান যে আপনার ডেটা সঠিকভাবে সুরক্ষিত নয়, তাহলে এই সাধারণ ত্রুটিগুলি পর্যালোচনা করুন এবং যেকোনো ঝুঁকিপূর্ণ নিয়ম আপডেট করুন।
আপনার Firebase Security Rules অ্যাক্সেস করুন
আপনার বিদ্যমান Rules দেখতে, Firebase CLI অথবা Firebase কনসোল ব্যবহার করুন। ভুল করে আপডেটগুলি ওভাররাইট করা এড়াতে, একই পদ্ধতি ব্যবহার করে আপনার নিয়মগুলি ধারাবাহিকভাবে সম্পাদনা করুন। যদি আপনি নিশ্চিত না হন যে আপনার স্থানীয়ভাবে সংজ্ঞায়িত নিয়মগুলি সাম্প্রতিক আপডেটগুলি প্রতিফলিত করে কিনা, তাহলে Firebase কনসোল সর্বদা আপনার Firebase Security Rules এর সাম্প্রতিকতম মোতায়েন করা সংস্করণটি দেখায়।
Firebase কনসোল থেকে আপনার নিয়মগুলি অ্যাক্সেস করতে, আপনার প্রকল্পটি নির্বাচন করুন, তারপর Realtime Database , Cloud Firestore অথবা Storage এ নেভিগেট করুন। সঠিক ডাটাবেস বা স্টোরেজ বাকেটে পৌঁছানোর পরে Rules এ ক্লিক করুন।
Firebase CLI থেকে আপনার নিয়মগুলি অ্যাক্সেস করতে, আপনার firebase.json ফাইলে উল্লিখিত নিয়ম ফাইলে যান।
Firebase Security Rules বুঝুন
Firebase Security Rules আপনার ডেটা ক্ষতিকারক ব্যবহারকারীদের হাত থেকে রক্ষা করে। যখন আপনি Firebase কনসোলে একটি ডাটাবেস ইনস্ট্যান্স বা Cloud Storage বাকেট তৈরি করেন, তখন আপনি সমস্ত ব্যবহারকারীর অ্যাক্সেস অস্বীকার করতে পারেন ( লকড মোড ) অথবা সমস্ত ব্যবহারকারীর অ্যাক্সেস মঞ্জুর করতে পারেন ( টেস্ট মোড )। যদিও আপনি ডেভেলপমেন্টের সময় আরও খোলা কনফিগারেশন চাইতে পারেন, আপনার অ্যাপ স্থাপনের আগে আপনার নিয়মগুলি সঠিকভাবে কনফিগার করার এবং আপনার ডেটা সুরক্ষিত করার জন্য সময় নিন।
যখন আপনি আপনার অ্যাপ ডেভেলপ করছেন এবং আপনার নিয়মের জন্য বিভিন্ন কনফিগারেশন পরীক্ষা করছেন, তখন স্থানীয় ডেভেলপমেন্ট পরিবেশে আপনার অ্যাপ চালানোর জন্য স্থানীয় ফায়ারবেস এমুলেটরগুলির একটি ব্যবহার করুন।
অনিরাপদ নিয়ম সহ সাধারণ পরিস্থিতি
আপনার অ্যাপটি ডিফল্টভাবে সেট করা অথবা অ্যাপটি তৈরির প্রাথমিক কাজ করার সময় আপনি যে 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 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 এর মাধ্যমে ব্যবহারকারী-ভিত্তিক নিরাপত্তা। নিয়ম ব্যবহার করে ব্যবহারকারীদের প্রমাণীকরণ সম্পর্কে আরও জানুন। Cloud FirestoreRealtime DatabaseCloud Storage |
যেকোনো অনুমোদিত ব্যবহারকারীর জন্য অ্যাক্সেস
কখনও কখনও, Rules পরীক্ষা করে যে কোনও ব্যবহারকারী লগ ইন করেছেন কিনা, কিন্তু সেই প্রমাণীকরণের উপর ভিত্তি করে অ্যাক্সেসকে আরও সীমাবদ্ধ করে না। যদি আপনার নিয়মগুলির মধ্যে একটিতে auth != null থাকে, তাহলে নিশ্চিত করুন যে আপনি চান যে কোনও লগ ইন করা ব্যবহারকারীর ডেটাতে অ্যাক্সেস থাকুক।
প্রস্তাবিত নয়: যেকোনো লগ-ইন করা ব্যবহারকারীর আপনার সম্পূর্ণ ডাটাবেসে পড়ার এবং লেখার অ্যাক্সেস আছে। Cloud Firestoreservice 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 FirestoreRealtime DatabaseCloud Storage |
( 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 Admin SDK এবং Cloud Functions এখনও আপনার ডাটাবেস অ্যাক্সেস করতে পারে। Firebase Admin SDK এর সাথে সার্ভার-অনলি ব্যাকএন্ড হিসেবে Cloud Firestore বা Realtime Database ব্যবহার করার সময় এই নিয়মগুলি ব্যবহার করুন। এটি নিরাপদ থাকা সত্ত্বেও, আপনার অ্যাপের ক্লায়েন্টরা সঠিকভাবে ডেটা পুনরুদ্ধার করতে পারে কিনা তা পরীক্ষা করা উচিত।
Cloud Firestore Security Rules এবং সেগুলি কীভাবে কাজ করে সে সম্পর্কে আরও জানুন "Get Started with Cloud Firestore Security Rules ।
আপনার Cloud Firestore Security Rules পরীক্ষা করুন
আপনার অ্যাপের আচরণ পরীক্ষা করতে এবং আপনার Cloud Firestore Security Rules কনফিগারেশন যাচাই করতে, ফায়ারবেস এমুলেটর ব্যবহার করুন। কোনও পরিবর্তন স্থাপন করার আগে স্থানীয় পরিবেশে ইউনিট পরীক্ষা চালানো এবং স্বয়ংক্রিয় করতে Cloud Firestore এমুলেটর ব্যবহার করুন।
Firebase কনসোলে Firebase Security Rules দ্রুত যাচাই করতে, Firebase Rules Simulator ব্যবহার করুন।