Firebase allow read, write: if true բացատրված․ ինչ է անում և ինչպես շտկել

Շարահյուսությունը, տող առ տող

Ամբողջական Firestore թեստ-ռեժիմի rules փաստաթուղթը վեց տող է․

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

Ապակոդավորված․

• rules_version = '2';-ը ընտրում է v2 rules engine-ը (ընթացիկ)։ Հին v1 rules-ները ժամկետանց են։
• service cloud.firestore-ը սահմանափակում է բլոկը Firestore-ով։ Realtime Database-ն օգտագործում է JSON-հիմքով տարբեր շարահյուսություն. Cloud Storage-ն օգտագործում է service firebase.storage։
• match /databases/{database}/documents-ը կապում է հատուկ (default) տվյալների բազան (նախագծերի մեծ մասն ունի միայն մեկը)։
• match /{document=**}-ը ռեկուրսիվ wildcard է։ **-ը համապատասխանում է ցանկացած խորության ցանկացած ուղու։ Համակցված {document}-ի հետ, սա գրավում է յուրաքանչյուր փաստաթուղթ յուրաքանչյուր collection-ում — մեկ match clause, որ կարգավորում է ամբողջ տվյալների բազան։
• allow read, write: if true;-ն կանոնի մարմինն է։ Թե՛ read-ը, թե՛ write-ն թույլատրված են. if true պայմանը, լավ, միշտ ճիշտ է։ read-ը ընդգրկում է get և list գործողությունները. write-ն ընդգրկում է create, update և delete։

Զուտ ազդեցություն․ Firebase project ID-ով և ճիշտ SDK-ով ցանկացած հաճախորդ կարող է կարդալ կամ գրել ցանկացած փաստաթուղթ ցանկացած collection-ում։ Վավերացում չի պահանջվում։ Rate limit-ներ չեն պարտադրվում։

Ինչու Firebase-ն այն առաքում է որպես լռելյայն

Firebase-ն ուզում է, որ դու կոդավորես առաջին 30 վայրկյանում նախագիծը ստեղծելուց հետո։ Այլընտրանքը — ստիպել քեզ ճիշտ կանոն գրել, քանի դեռ որևէ ընթերցում կամ գրառում աշխատում է — կարգելափակեր onboarding-ը։ Այսպիսով Console-ն առաջարկում է երկու տարբերակ, երբ տվյալների բազա ես ստեղծում․ Production mode (մերժել ամեն ինչ, դու կանոնները գրում ես) կամ Test mode (թույլատրել ամեն ինչ 30 օրով)։ Ծրագրավորողների մեծ մասը սեղմում է test mode, ապա մոռանում վերանայել։ Հին նախագծերը 30-օրյա ժամանակաչափիչ ունեին. ընթացիկ նախագծերը անժամկետ if true կանոն ունեն առանց ավտոմատ ժամկետի սպառման։

Կառուցվածքային խնդիրը․ AI-ի կոդավորման գործիքները մարզվում են փաստաթղթերի, ձեռնարկների և Stack Overflow պատասխանների վրա, որոնք ցույց են տալիս թեստ-ռեժիմի կանոնները։ Երբ դու հարցնում ես Cursor կամ Claude Code «ինչպես կարգավորել Firebase», պատասխանը հաճախ ներառում է ճշգրիտ allow read, write: if true բլոկը, կարծես այն production կանոնն է։ AI-ն չգիտի — և չի հուշվում, որ իմանա, — որ այս կանոնը production-ի համար անվտանգ չէ։

Ինչ է տեսնում հարձակվողը

Կոնկրետ, հարձակվողը, որ գիտի քո Firebase project ID-ն (հանված ցանկացած թողարկված հավելվածի bundle-ից 30 վայրկյանում), գործարկելով հետևյալը, կարող է թվարկել ամեն փաստաթուղթ ամեն collection-ում․

Մեկ չվավերացված curl հարցումը բավական է յուրաքանչյուր collection թվարկելու համար։ Տես ընդգծված բլոկը ստորև։

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

Պատասխանը վերին մակարդակի collection-ների ամբողջական ցուցակն է։ Յուրաքանչյուր collection-ի համար, երկրորդ հարցումը վերադարձնում է փաստաթղթեր։ Այս ուղու վրա rate limit չկա, որովհետև if true կանոնները ընդունում են անանուն տրաֆիկ։ Մենք տեսել ենք Firebase տվյալների բազաներ՝ միլիոնավոր փաստաթղթերով, թվարկված մեկ ժամից պակաս ժամանակում։

Գրառման ուղու վրա․ մեկ POST-ը {fields}-ով նոր փաստաթուղթ է ստեղծում։ Հարձակվողները կարող են աղտոտել քո collection-ները աղբով, աղավաղել օգտատերերի համար տեսանելի էջեր, որ կարդում են Firestore-ից, կամ քո տվյալների բազան օգտագործել որպես անվճար message broker — քո օգտագործման հաշիվը աճում է, դու հետաքննում ես, հաշիվը բացատրում է խնդիրը։

Չորս production-անվտանգ փոխարինումներ

Ընտրիր փոխարինումը, որ համապատասխանում է քո հավելվածի տվյալների մոդելին։ Բոլոր չորսը ենթադրում են, որ ունես օգտատերերի վավերացում (Firebase Auth կամ որևէ մատակարար, որ տալիս է Firebase ID token)․

Տարբերակ 1․ Օգտատիրոջ սեփական փաստաթղթեր

Ամենատարածված SaaS նմուշը։ Փաստաթղթերն ապրում են /users/{userId}/...-ի տակ, և միայն սեփականատերը կարող է դիպչել։ 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;
}

Տարբերակ 2․ Owner դաշտ յուրաքանչյուր փաստաթղթի վրա

Երբ փաստաթղթերը ապրում են հարթ collection-ներում (ոչ թե user ID-ի տակ ներդրված), պահիր 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; }

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;
}

Տարբերակ 3․ Բազմա-վարձակալական org մեկուսացում

B2B SaaS-ի համար org-սահմանված տվյալներով։ Պահիր org_id դաշտ յուրաքանչյուր փաստաթղթի վրա և ստուգիր այն օգտատիրոջ custom claim-ի դեմ։ allow read, write: if request.auth.token.org_id == resource.data.org_id;։ Պահանջում է գրանցման ժամանակ custom claim-ի սահմանում Firebase Admin SDK-ի միջոցով։

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

Տարբերակ 4․ Միայն-կարդալու հանրային բովանդակություն

Մարքեթինգային բովանդակության, հանրային պրոֆիլների, ապրանքների կատալոգների համար — ցանկացած բան, որ իսկապես հանրային-կարդալու, բայց միայն-ադմինի-գրառման է։ match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }։ admin custom claim-ը սահմանվում է միայն admin հաշիվների վրա։

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

Արագ աուդիտի հարցում

Շտկելուց առաջ ստուգիր, թե արդյոք if true-ն իրականում կենդանի է։ Բացիր Firebase Console → Firestore → Rules և որոնիր if true։ Եթե այն գտնում ես ինչ-որ տեղ՝ մեկնաբանությունից դուրս, ունես բաց-կանոնի գտածո։ Նույն UI-ի Rules simulator-ը թույլ է տալիս լոկալ կրկնել հարձակվողի հարցումը — տեղադրիր անանուն GET /users/somebody և հաստատիր, որ simulator-ը վերադարձնում է Allowed։

Արտաքին հաստատում․ գործարկիր FixVibe սկան քո production URL-ի դեմ։ baas.firebase-rules ստուգումը ստուգում է քո Firestore, Realtime Database և Storage rules-ը և հայտնում նույն գտածոն, որ հարձակվողը կհայտնագործեր — անկախ նրանից, թե ինչ է ցույց տալիս Firebase Console-ը։

Հաճախակի տրվող հարցեր

Հաջորդ քայլեր

Գործարկիր FixVibe սկան քո production URL-ի դեմ — baas.firebase-rules ստուգումը հաստատում է, թե արդյոք if true-ն այս պահին շահագործելի է հանրային ինտերնետից։ Սկաների մեխանիզմի և Realtime Database-ի ու Storage-ի զուգահեռ հայտնաբերումների համար տես Firebase rules սկաներ։ Supabase-ի վրա սխալ կարգավորման համարժեք դասի համար կարդա Supabase RLS սկաներ։