Сканер неправильных настроек BaaS: найдите публичные пути к данным раньше пользователей

Почему неправильные настройки 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

Webhook-и Clerk, webhook-и Stripe, webhook-и Supabase — все подписывают свои нагрузки. Обработчик, который не проверяет подпись, — это примитив записи в базу данных для любого злоумышленника, угадавшего URL. Обнаруживается через форму ответа — неподписанный запрос, который получает 200, означает, что проверка пропущена.

Как работает зонтичное сканирование FixVibe BaaS

Фаза BaaS FixVibe выполняется в три этапа, каждый из которых производит отдельные находки:

1. <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
2. Этап 2 — зонды, специфичные для поставщика. Для каждого обнаруженного поставщика сканер запускает специфичную для поставщика проверку: baas.supabase-rls зондирует PostgREST; baas.firebase-rules зондирует Firestore + RTDB + Storage; baas.clerk-auth0 проверяет префикс упакованных ключей; проверка секретов бандла подтверждает, что никакие учётные данные сервисного уровня не утекли. Каждый зонд работает независимо — находка Supabase не блокирует сканирование Firebase.
3. Этап 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, выполняет конкретную работу, которую другие инструменты не делают. Сравнение:

Честная область: что этот сканер не заменяет

Сканер DAST, осведомлённый о BaaS, — это сфокусированный инструмент, а не полная программа безопасности. Он не:

• Заменяет SAST или SCA. Статический анализ находит CVE зависимостей (Snyk, Semgrep) и уязвимости на уровне кода (SonarQube), которые сканер DAST не может. Запускайте оба.
• Заменяет ручное тестирование на проникновение. Человек-пентестер находит изъяны бизнес-логики, краевые случаи авторизации и связанные уязвимости, которые не может ни один сканер. Наймите пентестера перед крупным запуском или аудитом соответствия.
• Проверяет ваш код или репозиторий на наличие секретов в истории git. Проверка секретов бандла охватывает то, что сейчас развёрнуто, а не то, что было исторически закоммичено. Используйте git-secrets или gitleaks для гигиены репозитория.
• Охватывает не-BaaS бэкенд-сервисы. Если ваше приложение использует пользовательский бэкенд (Express, Rails, Django, FastAPI), FixVibe сканирует его HTTP-поверхность, но не зондирует базу данных или инфраструктуру за ним. Это территория общего DAST + SAST.

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

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

Запустите бесплатное сканирование FixVibe против вашего производственного URL — проверки фазы BaaS предоставляются на каждом тарифе, включая бесплатный. Для глубоких погружений, специфичных для поставщика, отдельные статьи в этом разделе детально охватывают каждого поставщика: Supabase RLS, Раскрытие сервисного ключа Supabase, Хранилище Supabase, Правила Firebase, Firebase if-true, Clerk и Auth0.