Skener chybnej konfigurácie BaaS: nájdite verejné dátové cesty skôr, než to urobia používatelia

Prečo majú BaaS chybné konfigurácie opakujúci sa tvar

Každá BaaS platforma sleduje rovnakú architektúru: spravovaný backend s tenkým klientskym SDK, ktoré s ním komunikuje z prehliadača. Klient zameraný na prehliadač potrebuje nejaké poverenie — anon kľúč, publishable kľúč, Firebase project ID — aby sa identifikoval voči backendu. To poverenie je zámerne verejné; bezpečnosť architektúry spočíva na tom, že kontroly prístupu na úrovni platformy (RLS, pravidlá, zoznamy povolených) robia svoju prácu.

AI nástroje na kódovanie stavajú na tejto architektúre bez internalizácie vrstvy kontrol platformy. Zapájajú klientske SDK správne, akceptujú voľné predvolené pravidlá platformy (ktoré existujú pre tutoriálovú priateľskosť) a odošlú. Opakujúci sa tvar je: verejné poverenie + voľné predvolené pravidlo + chýbajúce prepísanie = odhalenie dát. Päť tried chybných konfigurácií nižšie sú všetky varianty tohto tvaru.

Päť opakujúcich sa tried chybných konfigurácií

Tieto sa objavujú naprieč každým BaaS poskytovateľom. Úplný sken pokrýva všetkých päť proti každému používanému poskytovateľovi:

Trieda 1: Nesprávny kľúč v balíčku prehliadača

Prehliadač odosiela secret/admin kľúč (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) namiesto verejného/anon ekvivalentu. Prehliadač sa stáva neobmedzeným admin klientom. Pokryté kontrolou bundle-secrets od FixVibe.

Trieda 2: Vrstva kontroly prístupu vypnutá alebo voľná

RLS je vypnuté, Firebase pravidlá sú if true, Auth0 callback zoznam je so žolíkmi. Poverenie v prehliadači je správne — ale hranica na úrovni platformy, ktorá ho mala obmedziť, nerobí svoju prácu.

Trieda 3: Anonymné čítania citlivých zdrojov

Anonymne čitateľné Firestore kolekcie, anonymne vypisateľné Supabase storage koše, anonymne prístupné Auth0 management API. Sken sa pýta: „bez poverení, čo môžem čítať?"

Trieda 4: Artefakty testovacieho režimu v produkcii

Testovacie kľúče (pk_test_*, sb_test_*) v produkčnom nasadení; dev-mode Firebase aplikácie dosiahnuteľné z live domény; testovacie tenant Auth0 aplikácie so slabšími nastaveniami než produkcia. Sken porovnáva behové kľúče proti očakávaným produkčným predponám.

Trieda 5: Chýbajúce overovanie podpisu webhookov

Clerk webhooky, Stripe webhooky, Supabase webhooky všetky podpisujú svoje payloady. Handler, ktorý neoveruje podpis, je primitívom pre zápis do databázy pre akéhokoľvek útočníka, ktorý uhádne URL. Detegované cez tvar odpovede — nepodpísaná požiadavka, ktorá dostane 200, znamená, že overenie sa preskakuje.

Ako funguje zastrešujúci BaaS sken FixVibe

BaaS fáza FixVibe beží v troch fázach, 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áza 2 — sondy špecifické pre poskytovateľa. Pre každého detegovaného poskytovateľa skener spustí kontrolu špecifickú pre poskytovateľa: baas.supabase-rls sonduje PostgREST; baas.firebase-rules sonduje Firestore + RTDB + Storage; baas.clerk-auth0 validuje predponu zbalených kľúčov; kontrola bundle-secrets validuje, že žiadne poverenia na úrovni servisu neunikli. Každá sonda beží nezávisle — Supabase nález neblokuje Firebase sken.
3. Fáza 3 — krížová korelácia poskytovateľov. Skener krížovo odkazuje nálezy. Uniknutý Supabase kľúč servisnej role spolu s chýbajúcim RLS je závažnejší než ktorýkoľvek nález samostatne — správa to vynáša na povrch. Viacero poskytovateľov identity (Clerk + Auth0 + vlastná autentizácia) v rovnakej aplikácii je štrukturálny nález označený na revíziu.

Každá sonda je pasívna: nanajvýš jedno anonymné čítanie na zdroj, s tvarom odpovede zaznamenaným, ale obsahom riadkov nikdy nestránkovaným ani neukladaným. Sondy zápisu a úpravy sú podmienené overeným vlastníctvom domény — nikdy nebežia proti neovereným cieľom.

Čo skener nachádza na poskytovateľa

Každý BaaS poskytovateľ má iný povrch a inú stratégiu skenu. Tu je čo je pokryté:

• Supabase: chýbajúce RLS na tabuľkách, anonymne vypisateľné storage koše, uniknutý service_role JWT alebo sb_secret_* kľúč v balíčku, odhalené schémy cez anonymný OpenAPI výpis. Pozri Skener Supabase RLS a Kontrolný zoznam Storage.
• Firebase: pravidlá if true na Firestore, Realtime Database a Cloud Storage; anonymne vypisateľné Storage koše; chýbajúce vynucovanie App Check. Pozri Skener Firebase pravidiel a Vysvetlenie If-true pravidla.
• Clerk: zbalené sk_* secret kľúče, pk_test_* v produkcii, chýbajúce overovanie podpisu webhookov, žolíkové povolené originy. Pozri Kontrolný zoznam Clerk.
• Auth0: zbalené client secrets, zapnutý Implicit grant, žolíkové callback / logout URL, chýbajúce PKCE na SPA. Pozri Kontrolný zoznam Auth0.

Ako sa BaaS skener porovnáva so všeobecnými DAST a SAST nástrojmi

BaaS-vedomý skener robí konkrétnu prácu, ktorú iné nástroje nerobia. Porovnanie:

Úprimný rozsah: čo tento skener nenahrádza

BaaS-vedomý DAST skener je zameraný nástroj, nie úplný bezpečnostný program. Nerobí:

• Nenahrádza SAST ani SCA. Statická analýza nájde CVE závislostí (Snyk, Semgrep) a zraniteľnosti na úrovni kódu (SonarQube), ktoré DAST skener nemôže. Používajte oboje.
• Nenahrádza manuálne penetračné testovanie. Ľudský pentester nájde chyby v business logike, hraničné prípady autorizácie a reťazené zraniteľnosti, ktoré žiadny skener nedokáže. Najmite si pentestera pred veľkým spustením alebo compliance auditom.
• Neaudituje váš kód ani repo na secrets v git histórii. Kontrola bundle-secrets pokrýva to, čo je momentálne nasadené, nie to, čo bolo historicky commitnuté. Použite git-secrets alebo gitleaks pre hygienu repa.
• Nepokrýva ne-BaaS backendové služby. Ak vaša aplikácia používa vlastný backend (Express, Rails, Django, FastAPI), FixVibe skenuje jeho HTTP povrch, ale nesondoval databázu ani infraštruktúru za ňou. To je územie všeobecného DAST + SAST.

Často kladené otázky

Ďalšie kroky

Spustite bezplatný sken FixVibe proti vašej produkčnej URL — kontroly BaaS-fázy sa dodávajú v každom pláne vrátane bezplatnej úrovne. Pre hlboké ponory špecifické pre poskytovateľa pokrývajú jednotlivé články v tejto sekcii každého poskytovateľa podrobne: Supabase RLS, Odhalenie Supabase service-key, Supabase storage, Firebase pravidlá, Firebase if-true, Clerk a Auth0.