Firebase rules scanner: খোলা Firestore, Realtime Database, এবং Storage rules খুঁজুন

Scanner কীভাবে খোলা Firebase rules খুঁজে পায়

Firebase services সুপরিচিত, predictable URL shapes expose করে। credentials ছাড়া একটি scanner প্রতিটি probe করতে পারে এবং পর্যবেক্ষণ করতে পারে anonymous reads সফল হয় কিনা। FixVibe baas.firebase-rules check তিনটি স্বাধীন probes-এ চলে — প্রতি Firebase service-এ একটি:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database। Scanner https://[project-id]-default-rtdb.firebaseio.com/.json probe করে। যদি root anonymously readable হয়, response পুরো database tree JSON হিসাবে। একটি আরও রক্ষণশীল test .json?shallow=true query করে, যা শুধুমাত্র top-level keys return করে — যেকোনোভাবেই একটি finding।
• Cloud Storage। Scanner https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o query করে। যদি response authentication ছাড়া file names list করে, bucket anon-listable। Listable storage একটি finding যদিও individual file downloads denied — আক্রমণকারীরা guessable filenames খুঁজতে bucket enumerate করে।

Test-mode footgun আসলে কেমন দেখায়

Firebase-এর quickstart documentation-এ ইন্টারনেটে সবচেয়ে বেশি কপি করা rule blocks-এর একটি অন্তর্ভুক্ত রয়েছে:

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

Firebase একসময় এই rules-এ একটি স্বয়ংক্রিয় 30-দিনের expiry যোগ করত। এটি পরিবর্তন হয়েছে: আজ developer প্রতিস্থাপন না করলে rules চিরকাল persist করে। AI কোডিং টুলগুলি — যারা বছরের পর বছর documentation-এ প্রশিক্ষিত যাতে test-mode block অন্তর্ভুক্ত — প্রায়ই এটি verbatim emit করে এবং developer-কে বলে "এটি আপনার security rule।" এটি নয়।

অন্যান্য variants যা production-এ দেখায় কিন্তু সমানভাবে permissive:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• একটি future-timestamp variant: একটি rule যা ভবিষ্যতের একটি দূরের তারিখ পর্যন্ত সবকিছু অনুমতি দেয়। কখনো কার্যকরভাবে expire হয় না (উপরের highlighted block দেখুন)।
• allow read: if true; allow write: if request.auth != null; — public reads, যেকোনো authenticated user write করতে পারে।
• allow read, write: if request.auth != null; — যেকোনো signed-in user অন্য users-এর data সহ যেকোনো document পড়তে বা লিখতে পারে।

Scanner একটি খোলা rule খুঁজে পেলে কী করবেন

খোলা Firebase rules একটি runtime emergency। তিনটি services জুড়ে fix-এর একই আকার: একটি স্পষ্ট owner field-এর বিরুদ্ধে প্রতিটি rule-কে request.auth.uid-এ scope করুন। প্রতিটি service-এর নিজস্ব rule syntax আছে:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }। path-segment binding {userId} একমাত্র document হয়ে যায় যা user touch করতে পারে।

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

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }। Convention: users/[uid]/[filename]-এর অধীনে files সংরক্ষণ করুন এবং path-কে ownership প্রয়োগ করতে দিন।

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Firebase CLI-এর মাধ্যমে rules deploy করুন: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage। FixVibe scan পুনরায় চালিয়ে নতুন rules production-এ আছে যাচাই করুন — baas.firebase-rules finding clear হওয়া উচিত।

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

এটি Firebase-এর built-in tools-এর সাথে কীভাবে তুলনা করে

Firebase Console আপনাকে বর্তমান rules দেখায় কিন্তু runtime behaviour-এর বিরুদ্ধে audit করে না। Firebase Rules simulator আপনাকে synthetic requests-এর বিরুদ্ধে rule logic test করতে দেয় — দরকারী কিন্তু local। উভয় tool আপনাকে বলে না যে আপনার production rules public ইন্টারনেটে একজন anonymous আক্রমণকারীকে আসলে কী return করে। FixVibe (বা manual configuration সহ Burp Suite)-এর মতো একটি external scanner একমাত্র জিনিস যা একই কোণ থেকে probe করে যেখান থেকে একজন আক্রমণকারী করবে। Google-এর নিজস্ব App Check অপব্যবহার হ্রাস করে কিন্তু সঠিকভাবে-scoped rules-এর বিকল্প নয়।

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

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

আপনার production URL-এর বিরুদ্ধে একটি ফ্রি FixVibe scan চালান — baas.firebase-rules check প্রতিটি plan-এ ship হয় এবং Firestore, Realtime Database, এবং Cloud Storage জুড়ে খোলা rules flag করে। বিশেষত allow read, write: if true pattern-এর গভীর ব্যাখ্যার জন্য, Firebase allow read, write: if true ব্যাখ্যা দেখুন। Supabase, Firebase, Clerk, এবং Auth0 জুড়ে umbrella দৃশ্যের জন্য, BaaS misconfiguration scanner পড়ুন।