Сканер за Firebase правила: намерете отворени правила за Firestore, Realtime Database и Storage

Как скенерът намира отворени Firebase правила

Firebase услугите излагат добре известни, предсказуеми форми на URL. Скенер без credentials може да сондира всяка една и да наблюдава дали анонимните четения успяват. Проверката baas.firebase-rules на FixVibe работи в три независими сондажа — по един за всяка 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-а, за да намерят отгадаеми имена на файлове.

Как реално изглежда test-mode footgun-ът

Документацията quickstart на Firebase включва един от най-копираните блокове правила в интернет:

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

Firebase преди добавяше автоматичен 30-дневен срок на тези правила. Това се промени: днес правилата се запазват завинаги, освен ако разработчикът не ги замени. AI инструментите за кодиране — обучени през годините с документация, която включва test-mode блока — често го излъчват дословно и казват на разработчика "това е вашето правило за сигурност". Не е.

Други варианти, които се появяват в продукция, но са също толкова разрешителни:

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

• Вариант с timestamp в бъдещето: правило, което позволява всичко до дата далеч в бъдещето. Никога ефективно не изтича (вижте маркирания блок по-горе).
• allow read: if true; allow write: if request.auth != null; — публични четения, всеки автентикиран потребител може да пише.
• allow read, write: if request.auth != null; — всеки влязъл потребител може да чете или пише всеки документ, включително данните на други потребители.

Какво да направите, когато скенерът намери отворено правило

Отворените Firebase правила са runtime спешен случай. Поправката е със същата форма във всичките три услуги: ограничете всяко правило до request.auth.uid срещу явно поле за собственик. Всяка услуга има свой синтаксис за правила:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Path-сегментът {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 ви показва текущите правила, но не ги одитира спрямо runtime поведение. Симулаторът на Firebase Rules ви позволява да тествате логиката на правилата срещу синтетични заявки — полезно, но локално. Нито един инструмент не ви казва какво вашите production правила всъщност връщат на анонимен нападател в публичния интернет. Външен скенер като FixVibe (или Burp Suite с ръчна конфигурация) е единственото нещо, което сондира от същия ъгъл, от който би нападател. Собственият App Check на Google смекчава злоупотребата, но не замества правилно ограничените правила.

Често задавани въпроси

Следващи стъпки

Изпълнете безплатно 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.