// docs / baas security / umbrella scanner
Сканер неправильных настроек BaaS: найдите публичные пути к данным раньше пользователей
Поставщики Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — все терпят неудачу в безопасности в одной и той же форме: платформа поставляет разумные значения по умолчанию, разработчик (или ИИ-инструмент кодирования) тянется к ярлыку, и открывается публичный путь между неавторизованным злоумышленником и данными клиента. Сканер неправильных настроек BaaS — это единственный инструмент, который зондирует этот путь извне так, как это сделал бы злоумышленник. Эта статья отображает пять повторяющихся классов неправильных настроек, объясняет, как работает зонтичное сканирование FixVibe BaaS, сравнивает четырёх основных поставщиков и сопоставляет сканер, осведомлённый о BaaS, с общими инструментами DAST.
Почему неправильные настройки BaaS имеют повторяющуюся форму
Каждая платформа BaaS следует той же архитектуре: управляемый бэкенд с тонким клиентским SDK, который общается с ним из браузера. Клиенту, обращённому к браузеру, нужен некоторый учётный данные — ключ anon, публикуемый ключ, идентификатор проекта Firebase — чтобы идентифицировать себя бэкенду. Эти учётные данные намеренно публичные; безопасность архитектуры зависит от выполнения своей работы средствами контроля доступа на уровне платформы (RLS, правила, списки разрешённых).
ИИ-инструменты кодирования строят поверх этой архитектуры, не усваивая слой контроля платформы. Они правильно подключают клиентский SDK, принимают разрешающие правила по умолчанию платформы (которые существуют ради удобства учебных пособий) и выпускают. Повторяющаяся форма такова: публичные учётные данные + разрешающее правило по умолчанию + отсутствующее переопределение = раскрытие данных. Пять классов неправильных настроек ниже — это все варианты этой формы.
Пять повторяющихся классов неправильных настроек
Они появляются у каждого поставщика BaaS. Полное сканирование охватывает все пять у каждого используемого поставщика:
Класс 1: Неправильный ключ в браузерном бандле
Браузер отправляет секретный/админский ключ (Supabase service_role, частный ключ Firebase Admin SDK, Clerk sk_*, секрет клиента Auth0) вместо публичного/anon эквивалента. Браузер становится неограниченным админ-клиентом. Покрывается проверкой секретов бандла FixVibe.
Класс 2: Слой контроля доступа отключён или разрешающий
RLS отключен, правила Firebase — if true, список обратных вызовов Auth0 содержит подстановочные знаки. Учётные данные в браузере правильные — но граница уровня платформы, которая должна была их ограничивать, не выполняет свою работу.
Класс 3: Анонимные чтения чувствительных ресурсов
Анонимно читаемые коллекции Firestore, анонимно перечисляемые корзины хранилища Supabase, анонимно доступный API управления Auth0. Сканирование спрашивает: «без учётных данных, что я могу прочитать?»
Класс 4: Артефакты тестового режима в продакшене
Тестовые ключи (pk_test_*, sb_test_*) в продакшен-развёртывании; dev-mode приложения Firebase, доступные с живого домена; приложения Auth0 тестового арендатора с более слабыми настройками, чем продакшен. Сканирование сравнивает ключи времени выполнения с ожидаемыми производственными префиксами.
Класс 5: Отсутствие проверки подписи webhook
Clerk webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
Как работает зонтичное сканирование FixVibe BaaS
Фаза BaaS FixVibe выполняется в три этапа, каждый из которых производит отдельные находки:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- Этап 3 — кросс-поставщиковая корреляция. Сканер перекрёстно ссылается на находки. Утёкший ключ сервисной роли Supabase наряду с отсутствующим RLS более серьёзен, чем любая находка по отдельности — отчёт выделяет это. Несколько поставщиков удостоверений (Clerk + Auth0 + пользовательская аутентификация) в одном приложении — это структурная находка, помеченная для проверки.
Каждый зонд пассивен: не более одного анонимного чтения на ресурс, с зарегистрированной формой ответа, но содержимое строк никогда не разбивается на страницы и не сохраняется. Зонды записи и модификации защищены подтверждённым владением доменом — они никогда не запускаются против непроверенных целей.
Что сканер находит для каждого поставщика
У каждого поставщика BaaS своя поверхность и своя стратегия сканирования. Вот что покрывается:
- Supabase: отсутствующий RLS на таблицах, анонимно перечисляемые корзины хранилища, утёкший JWT
service_roleили ключsb_secret_*в бандле, схемы, раскрытые через анонимный список OpenAPI. См. Сканер Supabase RLS и Чек-лист хранилища. - Firebase: правила
if trueв Firestore, Realtime Database и Cloud Storage; анонимно перечисляемые корзины Storage; отсутствие принудительного применения App Check. См. Сканер правил Firebase и Объяснение правила if-true. - Clerk: упакованные секретные ключи
sk_*,pk_test_*в продакшене, отсутствие проверки подписи webhook, подстановочные разрешённые источники. См. Чек-лист Clerk. - Auth0: упакованные секреты клиента, включённый Implicit-грант, подстановочные URL обратного вызова / выхода, отсутствие PKCE на SPA. См. Чек-лист Auth0.
Как сканер BaaS сравнивается с общими инструментами DAST и SAST
Сканер, осведомлённый о BaaS, выполняет конкретную работу, которую другие инструменты не делают. Сравнение:
| Аспект | FixVibe (DAST с поддержкой BaaS) | Общий DAST (Burp / ZAP) | SAST / SCA (Снык/Семгреп) |
|---|---|---|---|
| Охват BaaS | Нативные проверки для Supabase, Firebase, Clerk, Auth0, Appwrite | Общий веб-обход; нет специфичных для поставщика зондов | Только статический анализ репозитория; нет проверки в продакшене |
| Время настройки | URL → run → results usually in under a minute | Часы: настройка паука, аутентификация, область | День: интеграция в CI репозитория |
| Что доказывает | Раскрытие во время выполнения в продакшене с доказательствами на уровне HTTP | Уязвимости веб-приложений (XSS, SQLi); BaaS через ручную настройку | Шаблоны кода, которые могут или не могут быть развёрнуты |
| Проверка JavaScript-бандла | Every shipped chunk, with provider-aware key detection | Ограничено — только grep на основе строк | Да, но только со стороны репозитория, не развёрнутого |
| Непрерывное сканирование | Ежемесячно / при развёртывании через API + MCP | Вручную; настройте расписание самостоятельно | По коммиту (хорошо для кода, слепо для времени выполнения) |
| Цена для соло / маленькой команды | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
Часто задаваемые вопросы
Работает ли зонтичное сканирование, если моё приложение использует двух поставщиков BaaS (например, Supabase + Clerk)?
Да — снятие отпечатков поставщика и зонды для каждого поставщика независимы. Сканер обнаруживает обоих, запускает обе наборы проверок и сообщает о кросс-поставщиковых корреляциях (например, JWT-шаблон Supabase от Clerk, который отправляет email как утверждение наряду с отсутствующим RLS).
Чем это отличается от запуска Burp Suite Pro против моего приложения?
Burp — это общий рабочий стол DAST. Из коробки Burp не знает, что такое PostgREST, Firestore или путь обратного вызова Auth0 — вам нужно вручную настроить область, написать расширения и интерпретировать ответы. FixVibe поставляется со встроенными зондами BaaS и форматированием доказательств в форме BaaS. Burp выигрывает в общем охвате веб-приложений (XSS, SQLi, бизнес-логика); FixVibe выигрывает в специфичных для BaaS находках.
А как насчёт App Check (Firebase) или аттестации (Apple / Google)?
App Check заставляет случайные внешние сканирования возвращать 403 на каждом зонде — правильный результат для злонамеренного бота. Сканирование FixVibe из неаттестованного клиента ведёт себя так же. Если у вас включен App Check и FixVibe всё ещё сообщает о находках, это означает, что ваши правила открыты и для аттестованных клиентов, что является реальным риском. App Check + правильные правила — это шаблон глубокой защиты.
Может ли сканер проверить моё исправление?
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
Следующие шаги
Запустите бесплатное сканирование FixVibe против вашего производственного URL — проверки фазы BaaS предоставляются на каждом тарифе, включая бесплатный. Для глубоких погружений, специфичных для поставщика, отдельные статьи в этом разделе детально охватывают каждого поставщика: Supabase RLS, Раскрытие сервисного ключа Supabase, Хранилище Supabase, Правила Firebase, Firebase if-true, Clerk и Auth0.