Firebase rules սկաներ․ գտիր բաց Firestore, Realtime Database և Storage rules

Ինչպես է սկաները գտնում բաց Firebase rules

Firebase ծառայությունները բացում են հայտնի, կանխատեսելի URL ձևեր։ Սկաներն առանց հավատարմագրերի կարող է ստուգել յուրաքանչյուրը և դիտել, թե արդյոք անանուն ընթերցումները հաջողվում են։ FixVibe-ի baas.firebase-rules ստուգումն աշխատում է երեք անկախ ստուգմամբ — մեկը Firebase ծառայության համար․

• <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։ Սկաները ստուգում է https://[project-id]-default-rtdb.firebaseio.com/.json։ Եթե արմատը անանուն ընթերցելի է, պատասխանն ամբողջ տվյալների բազայի ծառն է որպես JSON։ Ավելի պահպանողական թեստը հարցում է կատարում .json?shallow=true-ին, որը վերադարձնում է միայն վերին մակարդակի բանալիները — գտածո ամեն դեպքում։
• Cloud Storage։ Սկաները հարցում է կատարում https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o-ին։ Եթե պատասխանը ֆայլերի անունների ցուցակ է առանց վավերացման, bucket-ը anon-listable է։ Listable storage-ը գտածո է, նույնիսկ երբ առանձին ֆայլերի ներբեռնումները մերժվում են — հարձակվողները թվարկում են bucket-ը՝ կռահելի ֆայլերի անունները գտնելու համար։

Ինչպիսին է իրականում թեստ-ռեժիմի թակարդը

Firebase-ի quickstart փաստաթղթերը ներառում են ինտերնետի ամենաշատ պատճենահանված կանոնների բլոկներից մեկը․

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

Firebase-ը նախկինում ավելացնում էր ավտոմատ 30-օրյա ժամկետ այս կանոնների վրա։ Դա փոխվեց․ այսօր կանոնները մնում են ընդմիշտ, քանի դեռ ծրագրավորողը չի փոխարինում դրանք։ AI-ի կոդավորման գործիքները — տարիների փաստաթղթերի վրա մարզված, որոնք ներառում են թեստ-ռեժիմի բլոկը — հաճախ բառացիորեն թողարկում են այն և ծրագրավորողին ասում՝ «սա քո անվտանգության կանոնն է»։ Այն այդպիսին չէ։

Այլ տարբերակներ, որ ի հայտ են գալիս production-ում, բայց հավասարապես թույլատու են․

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

• Ապագա-ժամանակացույցի տարբերակ․ կանոն, որ թույլատրում է ամեն ինչ մինչև ապագայի հեռու ամսաթիվ։ Երբեք արդյունավետորեն չի սպառվում (տես ընդգծված բլոկը վերևում)։
• allow read: if true; allow write: if request.auth != null; — հանրային ընթերցումներ, ցանկացած վավերացված օգտատեր կարող է գրել։
• allow read, write: if request.auth != null; — ցանկացած մուտք գործած օգտատեր կարող է կարդալ կամ գրել ցանկացած փաստաթուղթ, ներառյալ այլ օգտատերերի տվյալները։

Ինչ անել, երբ սկաները գտնում է բաց կանոն

Բաց Firebase rules-ը runtime արտակարգ իրավիճակ է։ Շտկումը նույն ձևն ունի բոլոր երեք ծառայությունների համար․ սահմանափակիր յուրաքանչյուր կանոն request.auth.uid-ով հստակ սեփականատիրոջ դաշտի դեմ։ Յուրաքանչյուր ծառայություն ունի իր սեփական կանոնի շարահյուսությունը․

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }։ Ուղու-հատվածի կապումը {userId} դառնում է միակ փաստաթուղթը, որ օգտատերը կարող է դիպչել։

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; } } }։ Կանոն․ պահիր ֆայլերը users/[uid]/[filename] տակ և ուղուն թող պարտադրել սեփականությունը։

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

Deploy արա կանոնները Firebase CLI-ի միջոցով․ firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage։ Ստուգիր, որ նոր կանոնները production-ում են՝ կրկին գործարկելով FixVibe սկանը — baas.firebase-rules գտածոն պետք է մաքրվի։

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

Ինչպես է սա համեմատվում Firebase-ի ներկառուցված գործիքների հետ

Firebase Console-ը ցույց է տալիս ընթացիկ կանոնները, բայց չի աուդիտում դրանք runtime վարքի դեմ։ Firebase Rules simulator-ը թույլ է տալիս թեստավորել կանոնի տրամաբանությունը սինթետիկ հարցումների դեմ — օգտակար է, բայց լոկալ։ Ոչ մեկ գործիք քեզ չի ասում, թե ինչ են քո production կանոնները իրականում վերադարձնում հանրային ինտերնետում անանուն հարձակվողին։ Արտաքին սկաներ՝ ինչպիսին FixVibe-ն է (կամ Burp Suite-ը՝ ձեռքով կարգավորմամբ), միակ բանն է, որ ստուգում է նույն անկյունից, ինչից որ հարձակվողը կանի։ Google-ի սեփական App Check-ը մեղմում է չարաշահումը, բայց փոխարինող չէ ճիշտ-սահմանված կանոնների համար։

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

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

Գործարկիր անվճար FixVibe սկան քո production URL-ի դեմ — baas.firebase-rules ստուգումը առաքվում է բոլոր փաթեթներում և նշում է բաց կանոնները Firestore-ում, Realtime Database-ում և Cloud Storage-ում։ allow read, write: if true նմուշի ավելի խորը բացատրության համար տես Firebase allow read, write: if true բացատրված։ Supabase-ի, Firebase-ի, Clerk-ի և Auth0-ի միասնական տեսքի համար կարդա BaaS սխալ կարգավորման սկաներ։