Скенер за неправилни конфигурации на BaaS: намерете публични пътеки за данни, преди потребителите да го направят

Защо неправилните конфигурации на BaaS имат повтаряща се форма

Всяка BaaS платформа следва същата архитектура: управляван backend с тънък клиентски SDK, който комуникира с него от браузъра. Клиентът, обърнат към браузъра, се нуждае от някакъв идентификатор — anon ключ, публикуем ключ, Firebase project ID — за да се идентифицира пред backend. Този идентификатор е умишлено публичен; безопасността на архитектурата почива върху контролите за достъп на ниво платформа (RLS, rules, allowlists), които си вършат работата.

AI инструментите за кодиране се изграждат върху тази архитектура, без да усвояват слоя на платформените контроли. Те свързват клиентския SDK правилно, приемат разрешителните правила по подразбиране на платформата (които съществуват за tutorial-friendliness) и изпращат. Повтарящата се форма е: публичен идентификатор + разрешително правило по подразбиране + липсваща override = излагане на данни. Петте класа неправилни конфигурации по-долу са всички варианти на тази форма.

Петте повтарящи се класа неправилни конфигурации

Тези се появяват при всеки BaaS доставчик. Пълно сканиране покрива всичките пет срещу всеки използван доставчик:

Клас 1: Грешен ключ в браузърния bundle

Браузърът изпраща секретния/admin ключ (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) вместо публичния/anon еквивалент. Браузърът става неограничен admin клиент. Покрит от проверката bundle-secrets на FixVibe.

Клас 2: Слоят за контрол на достъпа е изключен или разрешителен

RLS е изключен, Firebase правилата са if true, списъкът на Auth0 callback е с wildcard. Идентификаторът в браузъра е правилният — но границата на ниво платформа, която трябваше да го ограничи, не си върши работата.

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

Anon-readable Firestore колекции, anon-listable Supabase storage bucket-и, anon-accessible Auth0 management API. Сканирането пита: "без идентификатори, какво мога да прочета?"

Клас 4: Test-mode артефакти в продукция

Test ключове (pk_test_*, sb_test_*) в production deploy; dev-mode Firebase приложения, достъпни от live домейн; test-tenant Auth0 приложения с по-слаби настройки от продукция. Сканирането сравнява runtime ключовете с очакваните production префикси.

Клас 5: Липсваща проверка на webhook подпис

Clerk webhooks, Stripe webhooks, Supabase webhooks всички подписват своите payloads. Handler, който не проверява подписа, е database-write primitive за всеки нападател, който отгатне 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 валидира префикса на bundled ключовете; проверката bundle-secrets валидира, че няма изтекли service-tier credentials. Всеки сондаж работи независимо — намираща се в Supabase не блокира Firebase сканирането.
3. Етап 3 — кръстосана корелация между доставчици. Скенерът прави cross-reference на находките. Изтекъл Supabase service-role ключ заедно с липсващ RLS е по-сериозен от която и да е находка сама — отчетът извежда това на показ. Множество доставчици на идентичност (Clerk + Auth0 + custom auth) в едно приложение е структурна находка, маркирана за преглед.

Всеки сондаж е пасивен: най-много едно анонимно четене на ресурс, със записана форма на отговора, но без съдържание на редове, което да се пагинира или съхранява. Сондажите за запис и модификация са ограничени до проверена собственост на домейна — те никога не се изпълняват срещу непроверени цели.

Какво намира скенерът на доставчик

Всеки BaaS доставчик има различна повърхност и различна стратегия за сканиране. Ето какво е покрито:

• Supabase: липсващ RLS на таблици, anon-listable storage bucket-и, изтекъл service_role JWT или sb_secret_* ключ в bundle, изложени схеми чрез анонимно OpenAPI listing. Вижте Сканер за Supabase RLS и Контролен списък за хранилище.
• Firebase: if true правила на Firestore, Realtime Database и Cloud Storage; anon-listable Storage bucket-и; липсващо налагане на App Check. Вижте Сканер за Firebase правила и Обяснение на правилото if-true.
• Clerk: bundled sk_* секретни ключове, pk_test_* в продукция, липсваща проверка на webhook подпис, wildcard разрешени origin-и. Вижте Контролен списък за Clerk.
• Auth0: bundled client secrets, Implicit grant активиран, wildcard callback / logout URLs, липсващ PKCE на SPAs. Вижте Контролен списък за Auth0.

Как BaaS скенерът се сравнява с общи DAST и SAST инструменти

BaaS-осведомен скенер върши специфична работа, която други инструменти не вършат. Сравнението:

Честен обхват: какво този скенер не замества

BaaS-осведомен DAST скенер е фокусиран инструмент, а не пълна програма за сигурност. Той не:

• Замества SAST или SCA. Статичният анализ намира dependency CVEs (Snyk, Semgrep) и code-level уязвимости (SonarQube), които DAST скенер не може. Стартирайте и двата.
• Замества ръчно penetration testing. Човек пентестър намира бизнес-логически недостатъци, ръбови случаи на оторизация и верижни уязвимости, които никой скенер не може. Наемете пентестър преди голямо изстрелване или одит за съответствие.
• Одитира кода или repo-то за тайни в git история. Проверката bundle-secrets покрива това, което е в момента деплойнато, а не това, което исторически е било commit-нато. Използвайте git-secrets или gitleaks за repo хигиена.
• Покрива non-BaaS backend услуги. Ако приложението ви използва custom backend (Express, Rails, Django, FastAPI), FixVibe сканира неговата HTTP повърхност, но не сондира базата данни или инфраструктурата зад нея. Това е територията на общ DAST + SAST.

Често задавани въпроси

Следващи стъпки

Изпълнете безплатно FixVibe сканиране срещу production URL — BaaS-фазовите проверки се включват във всеки план, включително безплатния. За дълбочинни прегледи на специфичните доставчици, отделните статии в този раздел покриват всеки доставчик подробно: Supabase RLS, Излагане на сервизен ключ на Supabase, Supabase хранилище, Firebase правила, Firebase if-true, Clerk и Auth0.