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

Чому неправильні налаштування BaaS мають повторювану форму

Кожна платформа BaaS дотримується тієї ж архітектури: керований бекенд із тонким клієнтським SDK, який спілкується з ним із браузера. Орієнтованому на браузер клієнту потрібні якісь облікові дані — ключ anon, публікований ключ, ID проєкту Firebase — щоб ідентифікуватися перед бекендом. Ці облікові дані навмисно публічні; безпека архітектури базується на тому, що контролі доступу на рівні платформи (RLS, rules, allowlists) виконують свою роботу.

ШІ-інструменти кодування будують поверх цієї архітектури без засвоєння шару контролів платформи. Вони підключають клієнтський SDK правильно, приймають значення за замовчуванням платформи з дозвільними правилами (які існують для зручності туторіалів) та постачають. Повторювана форма: публічні облікові дані + дозвільне правило за замовчуванням + відсутнє перевизначення = розкриття даних. П'ять класів неправильних налаштувань нижче — це всі варіанти цієї форми.

П'ять повторюваних класів неправильних налаштувань

Вони з'являються у кожного постачальника BaaS. Повне сканування покриває всі п'ять проти кожного використовуваного постачальника:

Клас 1: Неправильний ключ у браузерному бандлі

У браузер постачається секретний/admin ключ (Supabase service_role, приватний ключ Firebase Admin SDK, Clerk sk_*, клієнтський секрет Auth0) замість публічного/anon-еквівалента. Браузер стає необмеженим admin-клієнтом. Покривається перевіркою bundle-secrets FixVibe.

Клас 2: Шар контролю доступу вимкнено або дозвільно

RLS вимкнено, правила Firebase — if true, список callback Auth0 із wildcard. Облікові дані в браузері правильні — але межа на рівні платформи, призначена обмежувати їх, не виконує свою роботу.

Клас 3: Анонімні читання чутливих ресурсів

Анонімно-читані колекції Firestore, анонімно-перелічувані кошики сховища Supabase, анонімно-доступний Auth0 Management API. Сканування запитує: "без облікових даних, що я можу прочитати?"

Клас 4: Артефакти тестового режиму в продакшені

Тестові ключі (pk_test_*, sb_test_*) у продакшен-розгортанні; dev-режим застосунків Firebase, доступних із живого домену; тестові tenant-застосунки Auth0 зі слабшими налаштуваннями, ніж продакшен. Сканування порівнює ключі часу виконання з очікуваними продакшен-префіксами.

Клас 5: Відсутня перевірка підпису вебхуків

Вебхуки Clerk, вебхуки Stripe, вебхуки Supabase — усі підписують свої payload. Обробник, який не перевіряє підпис — це примітив запису в базу для будь-якого зловмисника, який вгадає URL. Виявляється через форму відповіді — непідписаний запит, що отримує 200, означає, що перевірку пропущено.

Як працює оглядове сканування BaaS FixVibe

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 валідує префікс ключів у бандлі; перевірка bundle-secrets валідує, що жодні облікові дані сервісного рівня не витекли. Кожен зонд виконується незалежно — знахідка Supabase не блокує сканування Firebase.
3. Етап 3 — кросс-провайдерська кореляція. Сканер перехресно посилається на знахідки. Витеклий ключ сервісної ролі Supabase разом із відсутнім RLS — серйозніше, ніж кожна з цих знахідок окремо — звіт виносить це на поверхню. Кілька провайдерів ідентичності (Clerk + Auth0 + користувацька auth) в одному застосунку — це структурна знахідка, позначена для перегляду.

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

Що сканер знаходить за постачальником

Кожен постачальник 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_* у продакшені, відсутня перевірка підпису вебхуків, wildcard у дозволених origin. Дивіться Чек-лист Clerk.
• Auth0: клієнтські секрети в бандлі, увімкнений Implicit grant, wildcard у callback / logout URL, відсутній PKCE на SPA. Дивіться Чек-лист Auth0.

Як сканер BaaS порівнюється із загальними DAST та SAST-інструментами

BaaS-обізнаний сканер виконує специфічну роботу, яку не роблять інші інструменти. Порівняння:

Чесна область: що цей сканер не замінює

BaaS-обізнаний DAST-сканер — це цільовий інструмент, а не повна програма безпеки. Він не:

• Замінює SAST або SCA. Статичний аналіз знаходить CVE залежностей (Snyk, Semgrep) та вразливості на рівні коду (SonarQube), які DAST-сканер не може. Запускайте обидва.
• Замінює ручний пентест. Людина-пентестер знаходить недоліки бізнес-логіки, граничні випадки авторизації та ланцюжкові вразливості, які жоден сканер не може. Найміть пентестера перед великим запуском або аудитом відповідності.
• Перевіряє ваш код або репозиторій на секрети в git-історії. Перевірка bundle-secrets покриває те, що наразі розгорнуто, а не те, що історично було закомічено. Використовуйте 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.