// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true ব্যাখ্যা: এটি কী করে এবং কীভাবে এটি ঠিক করবেন

Q: if true এবং if request.auth != null -এর মধ্যে পার্থক্য কী?

if true anonymous access অনুমতি দেয় — ইন্টারনেটে যে কেউ। if request.auth != null যেকোনো signed-in user প্রয়োজন, যা ভাল কিন্তু এখনো ভুল: আপনার অ্যাপের যেকোনো user প্রতিটি অন্য user-এর data পড়তে পারে। Production rules অবশ্যই request.auth.uid == resource.data.owner_uid বা অনুরূপ-এর মাধ্যমে নির্দিষ্ট user বা org-এ scope করতে হবে।

Q: Firebase কি কখনো স্বয়ংক্রিয়ভাবে if true rules expire করে?

পুরানো projects (pre-2023)-এ একটি 30-দিন timer ছিল যা if true rules-কে if false-এ রূপান্তর করে। বর্তমান projects-এ নেই — manually প্রতিস্থাপন না করা পর্যন্ত rule অনির্দিষ্টকালের জন্য persist করে। যদি আপনি 2023-এর আগে আপনার project তৈরি করেছিলেন এবং আপনার rules ঠিক দেখায়, তবুও যাচাই করুন: timer ইতিমধ্যে সেগুলিকে if false-এ flip করে দিয়ে থাকতে পারে, যা আপনার নিজস্ব অ্যাপকে block করে।

Q: আমার অ্যাপ যদি সত্যিই public-read হয় (blog, product catalog) তাহলে কী হবে?

তাহলে স্পষ্টভাবে শুধুমাত্র public collection-এ allow read: if true; allow write: if false; লিখুন — আপনার database-এর প্রতিটি collection-এ নয়। প্রতি collection-এ একটি পৃথক match clause ব্যবহার করুন এবং writable rules-এ কখনো recursive '{'document=**'}' wildcard ব্যবহার করবেন না।

<code>allow read, write: if true;</code> হল production-এ সবচেয়ে সাধারণ Firebase misconfiguration। এটি test-mode default যা Firebase Console আপনি একটি নতুন database তৈরি করার সময় প্রস্তাব করে, সেই rule যা AI কোডিং টুলগুলি documentation থেকে পুনরায় তৈরি করে, এবং সেই rule যা আপনার সমগ্র Firestore database-কে ইন্টারনেটের যে কারো জন্য খোলে। এই প্রবন্ধটি syntax-কে সঠিকভাবে ব্যাখ্যা করে, এই rule live থাকলে একজন আক্রমণকারী কী দেখে তা দেখায়, এবং আপনাকে চারটি ক্রমান্বয়ে-কঠোর প্রতিস্থাপন দেয় যা বিভিন্ন use cases-এ মানানসই।

syntax, line by line

একটি সম্পূর্ণ Firestore test-mode rules document ছয় লাইন:

firebase

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

Decoded:

rules_version = '2'; v2 rules engine (বর্তমান) নির্বাচন করে। পুরানো v1 rules deprecated।
service cloud.firestore block-কে Firestore-এ scope করে। Realtime Database একটি ভিন্ন JSON-ভিত্তিক syntax ব্যবহার করে; Cloud Storage service firebase.storage ব্যবহার করে।
match /databases/{database}/documents বিশেষ (default) database-কে bind করে (অধিকাংশ projects-এ শুধুমাত্র একটি)।
match /{document=**} একটি recursive wildcard। ** যেকোনো গভীরতার যেকোনো path match করে। {document}-এর সাথে সংযুক্ত, এটি প্রতিটি collection-এর প্রতিটি document ক্যাপচার করে — সমগ্র database শাসন করে এমন একটি একক match clause।
allow read, write: if true; হল rule body। read এবং write উভয়ই অনুমোদিত; condition if true, ভাল, সর্বদা সত্য। read get এবং list operations cover করে; write create, update, এবং delete cover করে।

Net effect: Firebase project ID এবং সঠিক SDK সহ যেকোনো client যেকোনো collection-এ যেকোনো document পড়তে বা লিখতে পারে। Authentication প্রয়োজন নেই। Rate limits প্রয়োগ করা হয় না।

Firebase কেন এটিকে default হিসাবে ship করে

Firebase চায় আপনি একটি project তৈরি করার পর প্রথম 30 সেকেন্ডে কোডিং করুন। বিকল্প — যেকোনো read বা write কাজ করার আগে আপনাকে একটি সঠিক rule লিখতে বাধ্য করা — onboarding ব্লক করবে। তাই Console আপনি database তৈরি করার সময় দুটি option প্রস্তাব করে: Production mode (সবকিছু deny করুন, আপনি rules লেখেন) বা Test mode (30 দিনের জন্য সবকিছু অনুমতি দিন)। অধিকাংশ developers test mode click করে, তারপর পুনরায় দেখতে ভুলে যায়। পুরানো projects-এ 30-দিন timer ছিল; বর্তমান projects-এ স্বয়ংক্রিয় expiry ছাড়াই একটি অনির্দিষ্ট if true rule।

Structural সমস্যা: AI কোডিং টুলগুলি documentation, tutorials, এবং Stack Overflow answers-এ প্রশিক্ষণ পায় যা test-mode rules দেখায়। আপনি যখন Cursor বা Claude Code-কে "আমি কীভাবে Firebase setup করব" জিজ্ঞাসা করেন, উত্তরে প্রায়ই সঠিক allow read, write: if true block এমনভাবে অন্তর্ভুক্ত থাকে যেন এটি production rule। AI জানে না — এবং জানার জন্য prompted নয় — যে এই rule production-এর জন্য নিরাপদ নয়।

একজন আক্রমণকারী কী দেখে

কংক্রিটভাবে, একজন আক্রমণকারী যে আপনার Firebase project ID জানে (যেকোনো deployed অ্যাপের bundle থেকে 30 সেকেন্ডে বের করা যায়) এবং নিম্নলিখিত চালায় সে প্রতিটি collection-এর প্রতিটি document list করতে পারে:

একটি একক unauthenticated curl request প্রতিটি collection enumerate করার জন্য যথেষ্ট। নিচের highlighted block দেখুন।

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

Response হল top-level collections-এর সম্পূর্ণ list। প্রতিটি collection-এর জন্য, একটি দ্বিতীয় request documents return করে। এই path-এ কোনো rate limit নেই কারণ if true rules anonymous traffic গ্রহণ করে। আমরা এক ঘণ্টার কম সময়ে enumerated লক্ষ লক্ষ documents সহ Firebase databases দেখেছি।

Write path-এ: {fields} সহ একটি একক POST একটি নতুন document তৈরি করে। আক্রমণকারীরা আপনার collections-কে garbage দিয়ে দূষিত করতে পারে, Firestore থেকে পড়া user-facing pages deface করতে পারে, বা আপনার database-কে একটি ফ্রি message broker হিসাবে ব্যবহার করতে পারে — আপনার usage bill বেড়ে যায়, আপনি investigate করেন, bill সমস্যা ব্যাখ্যা করে।

চারটি production-safe প্রতিস্থাপন

আপনার অ্যাপের data model-এর সাথে মেলে এমন প্রতিস্থাপন বেছে নিন। চারটিই ধরে নেয় আপনার user authentication আছে (Firebase Auth বা একটি Firebase ID token issue করে এমন যেকোনো provider):

Option 1: User-owned documents

সবচেয়ে সাধারণ SaaS pattern। Documents /users/{userId}/...-এর অধীনে থাকে এবং শুধুমাত্র owner সেগুলি touch করতে পারে। match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Option 2: প্রতিটি document-এ Owner field

যখন documents flat collections-এ থাকে (user ID-এর অধীনে nested নয়), একটি owner_uid field সংরক্ষণ করুন এবং এটি check করুন। match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Option 3: Multi-tenant org isolation

Org-scoped data সহ B2B SaaS-এর জন্য। প্রতিটি document-এ একটি org_id field সংরক্ষণ করুন এবং এটি user-এর custom claim-এর বিরুদ্ধে check করুন। allow read, write: if request.auth.token.org_id == resource.data.org_id;। Firebase Admin SDK-এর মাধ্যমে sign-up-এর সময় custom claim set করা প্রয়োজন।

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Option 4: Read-only public content

marketing content, public profiles, product catalogs-এর জন্য — যেকোনো কিছু যা সত্যিই public-read কিন্তু admin-only-write। match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }। admin custom claim শুধুমাত্র admin accounts-এ set করা হয়।

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

দ্রুত audit query

Fix-এর আগে, if true আসলে live কিনা check করুন। Firebase Console → Firestore → Rules খুলুন এবং if true খুঁজুন। যদি একটি comment-এর বাইরে কোথাও এটি খুঁজে পান, আপনার একটি খোলা-rule finding আছে। একই UI-তে Rules simulator আপনাকে আক্রমণকারীর request locally replay করতে দেয় — একটি anonymous GET /users/somebody paste করুন এবং confirm করুন যে simulator Allowed return করে।

External confirmation: আপনার production URL-এর বিরুদ্ধে একটি FixVibe scan চালান। baas.firebase-rules check আপনার Firestore, Realtime Database, এবং Storage rules probe করে এবং একজন আক্রমণকারী যে finding আবিষ্কার করবে তা রিপোর্ট করে — Firebase Console কী দেখায় তার থেকে স্বাধীন।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

<code>if true</code> এবং <code>if request.auth != null</code>-এর মধ্যে পার্থক্য কী?

if true anonymous access অনুমতি দেয় — ইন্টারনেটে যে কেউ। if request.auth != null যেকোনো signed-in user প্রয়োজন, যা ভাল কিন্তু এখনো ভুল: আপনার অ্যাপের যেকোনো user প্রতিটি অন্য user-এর data পড়তে পারে। Production rules অবশ্যই request.auth.uid == resource.data.owner_uid বা অনুরূপ-এর মাধ্যমে নির্দিষ্ট user বা org-এ scope করতে হবে।

Firebase কি কখনো স্বয়ংক্রিয়ভাবে <code>if true</code> rules expire করে?

পুরানো projects (pre-2023)-এ একটি 30-দিন timer ছিল যা if true rules-কে if false-এ রূপান্তর করে। বর্তমান projects-এ নেই — manually প্রতিস্থাপন না করা পর্যন্ত rule অনির্দিষ্টকালের জন্য persist করে। যদি আপনি 2023-এর আগে আপনার project তৈরি করেছিলেন এবং আপনার rules ঠিক দেখায়, তবুও যাচাই করুন: timer ইতিমধ্যে সেগুলিকে if false-এ flip করে দিয়ে থাকতে পারে, যা আপনার নিজস্ব অ্যাপকে block করে।

আমি কি একটি future-date timestamp check একটি safety net হিসাবে ব্যবহার করতে পারি?

না — একটি timestamp condition একটি security control নয়। এটি ভবিষ্যতের একটি তারিখে খোলা rule expire করে, যার মানে সেই তারিখ পর্যন্ত আক্রমণকারীদের পূর্ণ access আছে। এবং আপনি তারিখটি ভুলে যাবেন। if true-কে একটি auth-scoped rule দিয়ে প্রতিস্থাপন করুন, একটি time-bounded দিয়ে নয়।

আমার অ্যাপ যদি সত্যিই public-read হয় (blog, product catalog) তাহলে কী হবে?

তাহলে স্পষ্টভাবে শুধুমাত্র public collection-এ allow read: if true; allow write: if false; লিখুন — আপনার database-এর প্রতিটি collection-এ নয়। প্রতি collection-এ একটি পৃথক match clause ব্যবহার করুন এবং writable rules-এ কখনো recursive {document=**} wildcard ব্যবহার করবেন না।

পরবর্তী পদক্ষেপ

আপনার production URL-এর বিরুদ্ধে একটি FixVibe scan চালান — baas.firebase-rules check confirm করে if true বর্তমানে public ইন্টারনেট থেকে exploitable কিনা। Scanner mechanics এবং Realtime Database এবং Storage-এর সমান্তরাল detections-এর জন্য, Firebase rules scanner দেখুন। Supabase-এ misconfiguration-এর সমতুল্য class-এর জন্য, Supabase RLS scanner পড়ুন।