Сканер правил Firebase: знайдіть відкриті правила Firestore, Realtime Database та Storage

Як сканер знаходить відкриті правила Firebase

Сервіси Firebase надають добре відомі, передбачувані форми URL. Сканер без облікових даних може зондувати кожен із них і спостерігати, чи успішні анонімні читання. Перевірка 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. Якщо відповідь перелічує імена файлів без автентифікації, кошик доступний для анонімного переліку. Перелічуване сховище — це знахідка, навіть коли завантаження окремих файлів забороняються — зловмисники перераховують кошик, щоб знайти вгадувані імена файлів.

Як насправді виглядає підводний камінь тестового режиму

Документація швидкого старту Firebase містить один із найскопійованіших блоків правил в інтернеті:

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

Firebase раніше додавав автоматичний термін дії 30 днів на ці правила. Це змінилося: сьогодні правила зберігаються назавжди, якщо розробник їх не замінить. ШІ-інструменти кодування — натреновані на роках документації, що включає блок тестового режиму — часто видають його дослівно і кажуть розробнику "це ваше правило безпеки". Це не так.

Інші варіанти, які з'являються в продакшені, але так само дозвільні:

// 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 показує вам поточні правила, але не проводить їх аудит проти поведінки часу виконання. Симулятор правил Firebase дозволяє тестувати логіку правил проти синтетичних запитів — корисно, але локально. Жоден інструмент не каже вам, що ваші продакшен-правила насправді повертають анонімному зловмиснику в публічному інтернеті. Зовнішній сканер на кшталт FixVibe (або Burp Suite з ручною конфігурацією) — єдиний, що зондує з того ж кута, що й зловмисник. Власний App Check Google пом'якшує зловживання, але не замінює правильно обмежені правила.

Поширені запитання

Наступні кроки

Запустіть безкоштовне сканування 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.