Сканер правил 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.