Firebase rules scanner: ખુલ્લા Firestore, Realtime Database, અને Storage rules શોધો

Scanner ખુલ્લા Firebase rules કેવી રીતે શોધે છે

Firebase services well-known, predictable URL shapes expose કરે છે. Credentials વગરનો scanner દરેક ને probe કરી શકે છે અને જોઈ શકે છે કે anonymous reads સફળ થાય છે કે કેમ. FixVibe baas.firebase-rules check ત્રણ independent 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 પાછી આપે છે — બંને રીતે 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 છે ભલે વ્યક્તિગત file downloads denied હોય — હુમલાખોરો guessable filenames શોધવા bucket ને enumerate કરે છે.

Test-mode footgun ખરેખર કેવો દેખાય છે

Firebase ની quickstart documentation માં ઇન્ટરનેટ પર સૌથી વધુ copy કરાયેલા rule blocks માંથી એક છે:

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

Firebase આ rules પર automatic 30-day expiry ઉમેરતું હતું. તે બદલાયું: આજે rules ત્યાં સુધી કાયમ રહે છે જ્યાં સુધી developer તેમને replace ન કરે. AI કોડિંગ ટૂલ — જે વર્ષોની documentation પર trained છે જેમાં 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 થતું નથી (ઉપર highlight કરેલ block જુઓ).
• allow read: if true; allow write: if request.auth != null; — public reads, કોઈપણ authenticated user લખી શકે છે.
• allow read, write: if request.auth != null; — કોઈપણ signed-in user કોઈપણ document, અન્ય users ના data સહિત, વાંચી અથવા લખી શકે છે.

જ્યારે scanner ખુલ્લો rule શોધે ત્યારે શું કરવું

ખુલ્લા Firebase rules runtime કટોકટી છે. Fix બધી ત્રણ services માં એ જ shape ની છે: દરેક rule ને explicit owner field સામે 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 સ્પર્શ કરી શકે છે.

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; } } }. સંમેલન: files ને users/[uid]/[filename] હેઠળ store કરો અને path ને ownership enforce કરવા દો.

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 ફરી ચલાવીને production માં નવા rules છે તે verify કરો — baas.firebase-rules finding clear થવી જોઈએ.

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

આ Firebase ના built-in ટૂલ સાથે કેવી રીતે સરખાવાય

Firebase Console તમને વર્તમાન rules બતાવે છે પણ runtime behaviour સામે તેમનું audit નથી કરતું. Firebase Rules simulator તમને synthetic requests સામે rule logic test કરવા દે છે — ઉપયોગી પણ local. બેમાંથી કોઈ ટૂલ તમને જણાવતું નથી કે તમારા production rules public ઇન્ટરનેટ પર anonymous હુમલાખોર ને ખરેખર શું પાછું આપે છે. FixVibe જેવો બાહ્ય scanner (અથવા manual configuration સાથેનો Burp Suite) એકમાત્ર વસ્તુ છે જે હુમલાખોર જે angle થી probe કરશે એ જ angle થી probe કરે છે. Google નો પોતાનો App Check abuse ને mitigate કરે છે પણ correctly-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 પર ઊંડા explainer માટે, Firebase allow read, write: if true સમજાવાયું જુઓ. Supabase, Firebase, Clerk, અને Auth0 માં umbrella દૃશ્ય માટે, BaaS misconfiguration scanner વાંચો.