Firebase allow read, write: if true સમજાવાયું: તે શું કરે છે અને તેને કેવી રીતે fix કરવું

Syntax, line by line

સંપૂર્ણ Firestore test-mode rules document છ lines નો છે:

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

Decoded:

• rules_version = '2'; v2 rules engine (current) ની પસંદગી કરે છે. જૂના v1 rules deprecated છે.
• service cloud.firestore block ને Firestore સુધી scope કરે છે. Realtime Database અલગ JSON-based syntax નો ઉપયોગ કરે છે; Cloud Storage service firebase.storage નો ઉપયોગ કરે છે.
• match /databases/{database}/documents special (default) database ને bind કરે છે (મોટાભાગના projects પાસે ફક્ત એક હોય છે).
• match /{document=**} recursive wildcard છે. ** કોઈપણ depth ના કોઈપણ path સાથે મેળ ખાય છે. {document} સાથે જોડાયેલ, આ દરેક collection માં દરેક document ને capture કરે છે — એક single match clause જે સંપૂર્ણ database ને govern કરે છે.
• allow read, write: if true; rule body છે. read અને write બંને ની મંજૂરી છે; condition if true, સારું, હંમેશા true છે. read get અને list operations ને cover કરે છે; write create, update, અને delete ને cover કરે છે.

કુલ અસર: Firebase project ID અને યોગ્ય SDK ધરાવતો કોઈપણ client કોઈપણ collection માં કોઈપણ document વાંચી અથવા લખી શકે છે. Authentication ની જરૂર નથી. Rate limits enforce થતા નથી.

Firebase આને default તરીકે કેમ ship કરે છે

Firebase ઈચ્છે છે કે તમે project બનાવ્યા પછી પ્રથમ 30 સેકન્ડ માં coding કરી રહ્યા હો. વિકલ્પ — તમને કોઈપણ read અથવા write કામ કરે તે પહેલા સાચો rule લખવા મજબૂર કરવો — onboarding ને block કરશે. તેથી Console જ્યારે તમે database બનાવો ત્યારે બે options આપે છે: Production mode (બધું deny કરો, તમે rules લખો) અથવા Test mode (30 દિવસ માટે બધું મંજૂરી આપો). મોટાભાગના developers test mode ને click કરે છે, પછી પાછા જવાનું ભૂલી જાય છે. જૂના projects પાસે 30-day timer હતો; current projects પાસે કોઈ automatic expiry વગરનો અનિશ્ચિત if true rule છે.

Structural સમસ્યા: AI કોડિંગ ટૂલ documentation, tutorials, અને Stack Overflow answers પર train થાય છે જે test-mode rules બતાવે છે. જ્યારે તમે Cursor અથવા Claude Code ને પૂછો છો "હું Firebase કેવી રીતે set up કરું," ત્યારે જવાબમાં ઘણીવાર ચોક્કસ allow read, write: if true block હોય છે જાણે કે તે production rule હોય. AI જાણતું નથી — અને જાણવા માટે prompt નથી થતું — કે આ rule production માટે સુરક્ષિત નથી.

હુમલાખોર ને શું દેખાય છે

ઠોસ રૂપે, એક હુમલાખોર જે તમારો Firebase project ID જાણે છે (કોઈપણ deployed app ના bundle માંથી 30 સેકન્ડ માં કાઢી શકાય છે) અને નીચેનું ચલાવે છે, તે દરેક collection માં દરેક document list કરી શકે છે:

દરેક collection ને enumerate કરવા માટે એક single unauthenticated curl request પૂરતી છે. નીચે highlighted block જુઓ.

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 પાછા આપે છે. આ path પર કોઈ rate limit નથી કારણ કે if true rules anonymous traffic સ્વીકારે છે. અમે Firebase databases ને એક કલાક કરતા ઓછા સમય માં લાખો documents સાથે enumerated જોયા છે.

Write path પર: {fields} સાથેનો એક single POST નવો document બનાવે છે. હુમલાખોરો તમારી collections ને garbage થી pollute કરી શકે છે, Firestore માંથી વાંચતા user-facing pages ને deface કરી શકે છે, અથવા તમારા database ને મફત message broker તરીકે ઉપયોગ કરી શકે છે — તમારો usage bill વધે છે, તમે તપાસ કરો છો, bill સમસ્યા સમજાવે છે.

ચાર production-safe replacements

તમારી app ના data model સાથે મેળ ખાતું replacement પસંદ કરો. બધા ચાર ધારે છે કે તમારી પાસે user authentication છે (Firebase Auth અથવા Firebase ID token ઈશ્યુ કરતો કોઈપણ provider):

Option 1: User-owned documents

સૌથી સામાન્ય SaaS pattern. Documents /users/{userId}/... હેઠળ રહે છે અને ફક્ત owner તેમને સ્પર્શ કરી શકે છે. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

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 store કરો અને તેને 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; }

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 store કરો અને તેને user ના custom claim સામે check કરો. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Firebase Admin SDK મારફતે sign-up દરમ્યાન custom claim સેટ કરવાની જરૂર છે.

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 પર સેટ થાય છે.

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

ઝડપી audit query

Fix કરતા પહેલા, check કરો કે if true ખરેખર live છે કે કેમ. Firebase Console → Firestore → Rules ખોલો અને if true શોધો. જો તમે તેને comment ની બહાર ક્યાંય શોધો, તો તમારી પાસે open-rule finding છે. એ જ UI માં Rules simulator તમને હુમલાખોર ની request ને locally replay કરવા દે છે — anonymous GET /users/somebody paste કરો અને confirm કરો કે simulator Allowed પાછું આપે છે.

બાહ્ય confirmation: તમારા production URL સામે FixVibe scan ચલાવો. baas.firebase-rules check તમારા Firestore, Realtime Database, અને Storage rules ને probe કરે છે અને એ જ finding report કરે છે જે હુમલાખોર શોધશે — Firebase Console જે બતાવે છે તેનાથી independent.

વારંવાર પૂછાતા પ્રશ્નો

આગળના પગલાં

તમારા production URL સામે FixVibe scan ચલાવો — baas.firebase-rules check confirm કરે છે કે if true હાલમાં public ઇન્ટરનેટ થી exploitable છે કે કેમ. Scanner mechanics અને Realtime Database અને Storage માટે parallel detections માટે, Firebase rules scanner જુઓ. Supabase પર misconfiguration ની સમકક્ષ class માટે, Supabase RLS scanner વાંચો.