Skener chybných konfigurací BaaS: najděte veřejné datové cesty dříve než uživatelé

Proč mají chybné konfigurace BaaS opakující se tvar

Každá BaaS platforma má stejnou architekturu: spravovaný backend s tenkým klient SDK, který s ním komunikuje z prohlížeče. Klient orientovaný na prohlížeč potřebuje nějaký přihlašovací údaj — anon klíč, publishable klíč, ID projektu Firebase — aby se identifikoval backendu. Tento přihlašovací údaj je úmyslně veřejný; bezpečnost architektury spočívá na tom, že kontroly přístupu na úrovni platformy (RLS, pravidla, allowlisty) dělají svou práci.

AI nástroje pro kódování staví na této architektuře, aniž by si internalizovaly vrstvu kontrol platformy. Zapojují klient SDK správně, přijímají výchozí permisivní pravidla platformy (která existují pro tutoriálovou přívětivost) a vydávají. Opakující se tvar je: veřejný přihlašovací údaj + výchozí permisivní pravidlo + chybějící override = vystavení dat. Pět tříd chybných konfigurací níže jsou všechny varianty tohoto tvaru.

Pět opakujících se tříd chybných konfigurací

Objevují se u každého poskytovatele BaaS. Kompletní sken pokrývá všech pět proti každému používanému poskytovateli:

Třída 1: Špatný klíč v balíčku prohlížeče

Prohlížeč odesílá secret/admin klíč (Supabase service_role, Firebase Admin SDK privátní klíč, Clerk sk_*, Auth0 client secret) místo veřejného/anon ekvivalentu. Prohlížeč se stává neomezeným admin klientem. Pokryto FixVibe kontrolou bundle-secrets.

Třída 2: Vrstva kontroly přístupu vypnutá nebo permisivní

RLS je vypnuté, Firebase pravidla jsou if true, callback list Auth0 má wildcard. Přihlašovací údaj v prohlížeči je správný — ale hranice na úrovni platformy, která ho měla omezit, svou práci nedělá.

Třída 3: Anonymní čtení citlivých zdrojů

Anonymně čitelné kolekce Firestore, anonymně vypsatelné koše úložiště Supabase, anonymně dostupné Auth0 management API. Sken se ptá: "bez přihlašovacích údajů, co mohu číst?"

Třída 4: Artefakty test-mode v produkci

Testovací klíče (pk_test_*, sb_test_*) v produkčním nasazení; dev-mode Firebase aplikace dosažitelné z živé domény; testovací-tenant Auth0 aplikace se slabším nastavením než produkce. Sken porovnává runtime klíče s očekávanými produkčními prefixy.

Třída 5: Chybí ověření podpisu webhooku

Webhooky Clerk, Stripe webhooky, Supabase webhooky — všechny podepisují své payloady. Handler, který neověřuje podpis, je primitivem pro zápis do databáze pro jakéhokoliv útočníka, který uhádne URL. Detekováno přes tvar odpovědi — nepodepsaný požadavek, který dostane 200, znamená, že je ověření přeskočeno.

Jak funguje zastřešující BaaS sken FixVibe

BaaS fáze FixVibe probíhá ve třech fázích, každá produkuje odlišné nálezy:

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. Fáze 2 — sondy specifické pro poskytovatele. Pro každého detekovaného poskytovatele skener spouští kontrolu specifickou pro poskytovatele: baas.supabase-rls sonduje PostgREST; baas.firebase-rules sonduje Firestore + RTDB + Storage; baas.clerk-auth0 validuje prefix klíčů v balíčku; kontrola bundle-secrets validuje, že neunikly žádné přihlašovací údaje servisní úrovně. Každá sonda běží nezávisle — Supabase nález neblokuje Firebase sken.
3. Fáze 3 — křížová korelace mezi poskytovateli. Skener křížově odkazuje nálezy. Uniklý klíč servisní role Supabase vedle chybějícího RLS je závažnější než kterýkoliv nález sám — zpráva to nadnese. Více poskytovatelů identity (Clerk + Auth0 + vlastní auth) ve stejné aplikaci je strukturální nález označený k revizi.

Každá sonda je pasivní: maximálně jedno anonymní čtení na zdroj, s tvarem odpovědi zaznamenaným, ale obsah řádku se nikdy nestránkuje ani neukládá. Sondy zápisu a úpravy jsou podmíněny ověřeným vlastnictvím domény — nikdy nestřílejí proti neověřeným cílům.

Co skener u jednotlivých poskytovatelů najde

Každý poskytovatel BaaS má jiný povrch a jinou strategii skenování. Co je pokryto:

• Supabase: chybějící RLS na tabulkách, anonymně vypsatelné úložné koše, uniklý JWT service_role nebo klíč sb_secret_* v balíčku, vystavené schémata přes anonymní výpis OpenAPI. Viz Skener Supabase RLS a Kontrolní seznam úložiště.
• Firebase: pravidla if true na Firestore, Realtime Database a Cloud Storage; anonymně vypsatelné Storage koše; chybějící vynucení App Check. Viz Skener pravidel Firebase a Vysvětlení pravidla if-true.
• Clerk: klíče sk_* secret v balíčku, pk_test_* v produkci, chybějící ověření podpisu webhooku, wildcard povolené origins. Viz Kontrolní seznam Clerk.
• Auth0: client secrets v balíčku, povolený Implicit grant, wildcard callback / logout URL, chybějící PKCE na SPA. Viz Kontrolní seznam Auth0.

Jak srovnává BaaS skener s obecnými DAST a SAST nástroji

Skener s povědomím o BaaS dělá specifickou práci, kterou jiné nástroje nedělají. Srovnání:

Upřímný rozsah: co tento skener nenahrazuje

DAST skener s povědomím o BaaS je zaměřený nástroj, ne kompletní bezpečnostní program. Nedělá:

• Nenahrazuje SAST nebo SCA. Statická analýza najde závislostní CVE (Snyk, Semgrep) a zranitelnosti na úrovni kódu (SonarQube), které DAST skener nedokáže. Spusťte oboje.
• Nenahrazuje manuální penetrační testování. Lidský pentester najde chyby business logiky, autorizační okrajové případy a zřetězené zranitelnosti, které žádný skener nedokáže. Najměte si pentestera před velkým spuštěním nebo auditem souladu.
• Neaudituje váš kód nebo repo na tajemství v git historii. Kontrola bundle-secrets pokrývá to, co je aktuálně nasazené, nikoliv to, co bylo historicky zacommitováno. Pro hygienu repa použijte git-secrets nebo gitleaks.
• Nepokrývá ne-BaaS backendové služby. Pokud vaše aplikace používá vlastní backend (Express, Rails, Django, FastAPI), FixVibe skenuje jeho HTTP povrch, ale nesonduje databázi nebo infrastrukturu za ním. To je území obecného DAST + SAST.

Často kladené otázky

Další kroky

Spusťte bezplatný FixVibe sken proti vaší produkční URL — BaaS-fázové kontroly se dodávají na každém tarifu, včetně bezplatné úrovně. Pro hluboké ponoření do jednotlivých poskytovatelů pokrývají jednotlivé články v této sekci každého poskytovatele podrobně: Supabase RLS, vystavení servisního klíče Supabase, úložiště Supabase, pravidla Firebase, Firebase if-true, Clerk a Auth0.