FixVibe

// docs / baas security / firebase rules scanner

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

Приложения Firebase терпят неудачу в безопасности одним и тем же последовательным образом: правила allow read, write: if true;, оставшиеся от быстрого старта в тестовом режиме, никогда не заменяются перед продакшеном. ИИ-инструменты кодирования генерируют эти правила дословно из примеров документации и редко побуждают разработчика их усилить. Эта статья показывает, как сканер правил Firebase обнаруживает открытые правила в Firestore, Realtime Database и Cloud Storage извне проекта — и как исправить то, что он находит.

Как сканер находит открытые правила Firebase

Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:

  • Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
  • Realtime Database. FixVibe reports a database whose data anonymous visitors can read — often the whole tree at once.
  • Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.

Как на самом деле выглядит подводный камень тестового режима

Документация быстрого старта Firebase включает один из самых копируемых блоков правил в интернете:

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

Firebase раньше добавлял автоматический 30-дневный срок действия к этим правилам. Это изменилось: сегодня правила сохраняются навсегда, если разработчик их не заменит. ИИ-инструменты кодирования — обученные на годах документации, которая включает блок тестового режима — часто выдают его дословно и говорят разработчику «это ваше правило безопасности». Это не так.

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

firebase
// 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} становится единственным документом, к которому пользователь может прикоснуться.

firebase
match /users/{userId} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

База данных реального времени

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }. Подстановочный знак $uid захватывает сегмент пути для сравнения.

json
{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Облачное хранилище

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Соглашение: храните файлы по адресу users/[uid]/[filename] и позвольте пути обеспечить владение.

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

Deploy rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan — the open-rules finding should clear.

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

Как это сравнивается с встроенными инструментами Firebase

Консоль Firebase показывает вам текущие правила, но не проверяет их относительно поведения времени выполнения. Симулятор правил Firebase позволяет тестировать логику правил против синтетических запросов — полезно, но локально. Ни один инструмент не говорит вам, что ваши продакшен-правила на самом деле возвращают анонимному злоумышленнику в публичном интернете. Внешний сканер вроде FixVibe (или Burp Suite с ручной конфигурацией) — это единственное, что зондирует с того же угла, с которого злоумышленник. Собственный App Check от Google смягчает злоупотребление, но не заменяет правильно ограниченные правила.

Часто задаваемые вопросы

Будет ли сканер читать или изменять мои данные Firestore?

Пассивные сканирования выдают не более одного анонимного чтения на сервис, чтобы подтвердить, разрешают ли правила. Сканер записывает форму ответа и наличие данных — он не разбивает на страницы, не перечисляет документы и не пишет. Зонды записи защищены подтверждённым владением доменом и никогда не запускаются против непроверенных целей.

Что, если мой проект Firebase использует App Check?

App Check отклоняет неаутентифицированные запросы с 403. Сканер без токена App Check увидит 403 на каждом зонде — это правильный результат. App Check не является заменой правильности правил (украденный токен App Check плюс открытое правило всё равно утекает данные), но он блокирует случайные внешние сканирования.

Может ли сканер обнаруживать частичные неправильные настройки правил (чтение открыто, запись закрыта)?

Yes. Open read access and open write access are reported as separate findings, because data exfiltration and data manipulation are separate risks.

Работает ли это для приложений Firebase, развёрнутых под пользовательским доменом?

Да. Сканер извлекает идентификатор проекта Firebase из развёрнутого бандла, а не из домена. Пользовательские домены, поддомены app.web.app и самостоятельно размещённые приложения Firebase работают одинаково, пока JavaScript-бандл доступен.

Следующие шаги

Run a free FixVibe scan against your production URL — the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.

// сканируйте вашу baas-поверхность

Найдите открытую таблицу раньше, чем это сделает кто-то другой.

Введите производственный URL. FixVibe перечислит поставщиков BaaS, с которыми взаимодействует ваше приложение, снимет отпечатки с их публичных конечных точек и сообщит, что неавторизованный клиент может прочитать или записать. Бесплатно, без установки, без карты.

  • Бесплатный тариф — 3 сканирования в месяц, без карты при регистрации.
  • Пассивное снятие отпечатков BaaS — не требуется проверка владения доменом.
  • Supabase, Firebase, Clerk, Auth0, Appwrite и другие.
  • Coding-agent prompts where code/config applies, plus provider-console steps for hosted BaaS fixes.
Сканер правил Firebase: найдите открытые правила Firestore, Realtime Database и Storage · FixVibe