Firebase rules სკანერი: იპოვეთ ღია Firestore-, Realtime Database- და Storage-წესები

როგორ პოულობს სკანერი ღია Firebase-წესებს

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-ს. თუ პასუხი ჩამოთვლის ფაილების სახელებს ავთენტიფიკაციის გარეშე, ბაკეტი anon-listable-ია. Listable storage არის აღმოჩენა მაშინაც, როცა ცალკეული ფაილების ჩამოტვირთვა აკრძალულია — თავდამსხმელები ჩამოთვლიან ბაკეტს გასაცნობი ფაილების სახელების მოსაძებნად.

რას ნამდვილად ჰგავს ტესტ-რეჟიმის ხაფანგი

Firebase-ის სწრაფი დაწყების დოკუმენტაცია შეიცავს ერთ-ერთ ყველაზე გადაკოპირებულ წესების ბლოკს ინტერნეტში:

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

Firebase ადრე ამატებდა ავტომატურ 30-დღიან ვადის გასვლას ამ წესებზე. ეს შეიცვალა: დღეს წესები სამუდამოდ რჩება, თუ დეველოპერი მათ არ შეცვლის. AI-კოდირების ხელსაწყოები — გაწვრთნილი წლების დოკუმენტაციაზე, რომელიც შეიცავს ტესტ-რეჟიმის ბლოკს — ხშირად აგენერირებენ მას სიტყვა-სიტყვით და ეუბნებიან დეველოპერს „ეს არის თქვენი უსაფრთხოების წესი". არ არის.

სხვა ვარიანტები, რომლებიც ჩნდება პროდუქციაში, მაგრამ თანაბრად დასაშვებია:

// 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-წესები არის საგანგებო რეჟიმის სიტუაცია. გასწორება ერთი და იგივე ფორმისაა სამივე სერვისზე: მიაცილეთ ყოველი წესი 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;
    }
  }
}

გადააგზავნეთ წესები Firebase CLI-ით: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. დაამოწმეთ, რომ ახალი წესები პროდუქციაშია FixVibe-სკანის თავიდან გაშვებით — baas.firebase-rules აღმოჩენა უნდა გაიწმინდოს.

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

როგორ ედარება ეს Firebase-ის ჩაშენებულ ხელსაწყოებს

Firebase Console გიჩვენებთ მიმდინარე წესებს, მაგრამ ისინი არ აუდიტდება გაშვების ქცევის წინააღმდეგ. Firebase Rules-სიმულატორი გაძლევთ წესის ლოგიკის შემოწმებას სინთეტიკური მოთხოვნების წინააღმდეგ — სასარგებლო, მაგრამ ლოკალური. არც ერთი ხელსაწყო არ გეუბნებათ, რას ნამდვილად აბრუნებს თქვენი პროდუქციის წესები ანონიმურ თავდამსხმელს საჯარო ინტერნეტში. გარე სკანერი, როგორიც FixVibe (ან Burp Suite ხელით კონფიგურაციით) არის ერთადერთი, რომელიც ამოწმებს იმავე კუთხიდან, როგორც თავდამსხმელი იქნებოდა. Google-ის საკუთარი App Check არბილებს ბოროტ გამოყენებას, მაგრამ არ ცვლის სწორად-მიცილებულ წესებს.

ხშირად დასმული შეკითხვები

შემდეგი ნაბიჯები

გაუშვით უფასო FixVibe-სკანი თქვენი პროდუქციის 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-ის არასწორი კონფიგურაციის სკანერი.