BaaS hibás konfiguráció szkenner: találd meg a nyilvános adatútvonalakat, mielőtt a felhasználók tennék

Miért visszatérő alakúak a BaaS-hibakonfigurációk

Minden BaaS-platform ugyanazt az architektúrát követi: egy menedzselt backend egy vékony kliens-SDK-val, ami a böngészőből beszél vele. A böngésző-felé álló kliensnek valamilyen credential kell — egy anon kulcs, egy publishable kulcs, egy Firebase projekt-azonosító — hogy azonosítsa magát a backend felé. Ez a credential szándékosan nyilvános; az architektúra biztonsága a platform-szintű hozzáférés-kontrolloktól (RLS, rules, allowlistok) függ, hogy elvégzik a dolgukat.

Az MI-kódoló eszközök ennek az architektúrának a tetejére építenek, anélkül, hogy belsővé tennék a platform-kontroll-réteget. Bedrótozzák a kliens-SDK-t helyesen, elfogadják a platform alapértelmezett megengedő szabályait (amelyek oktatóanyag-barátságból léteznek), és élesítenek. A visszatérő alak: publikus credential + megengedő alapértelmezett szabály + hiányzó felülírás = adatkitettség. Az alábbi öt hibás-konfigurációs osztály mind ennek az alaknak a változatai.

Az öt visszatérő hibás-konfigurációs osztály

Ezek minden BaaS-szolgáltatón megjelennek. Egy teljes szkennelés mind az ötöt lefedi minden használt szolgáltatón:

1. osztály: Rossz kulcs a böngészőbundle-ben

A böngésző a secret/admin kulcsot szállítja (Supabase service_role, Firebase Admin SDK privát kulcs, Clerk sk_*, Auth0 client secret) a publikus/anon megfelelő helyett. A böngésző korlátlan admin-kliensé válik. Lefedi a FixVibe bundle-secrets ellenőrzése.

2. osztály: A hozzáférés-kontroll réteg letiltva vagy megengedő

Az RLS ki van kapcsolva, a Firebase rules if true, az Auth0 callback-lista wildcarddal van. A böngészőben lévő credential a helyes — de a platform-szintű határ, ami korlátozta volna, nem végzi a dolgát.

3. osztály: Érzékeny erőforrások anonim olvasása

Anonim módon olvasható Firestore-kollekciók, anonim módon listázható Supabase storage bucketök, anonim módon elérhető Auth0 management API. A szkennelés azt kérdezi: „credentialek nélkül mit tudok olvasni?"

4. osztály: Test-mode-melléktermékek a produkcióban

Teszt kulcsok (pk_test_*, sb_test_*) egy produkciós deploy-ban; dev-mode Firebase-alkalmazások elérhetőek az élő doménből; teszt-tenant Auth0-alkalmazások gyengébb beállításokkal, mint a produkció. A szkennelés a futtatási idejű kulcsokat hasonlítja az elvárt produkciós előtagokkal.

5. osztály: Hiányzó webhook-aláírás-ellenőrzés

A Clerk webhookjai, Stripe webhookjai, Supabase webhookjai mind aláírják a payloadjaikat. Egy handler, ami nem ellenőrzi az aláírást, adatbázis-írási primitív bármely támadó számára, aki kitalálja az URL-t. Válaszforma alapján detektálható — egy aláíratlan kérés, ami 200-at kap, azt jelenti, hogy az ellenőrzés ki van hagyva.

Hogyan működik a FixVibe ernyő BaaS-szkennelés

A FixVibe BaaS-fázisa három fázisban fut, mindegyik különböző találatokat termel:

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. fázis — szolgáltató-specifikus szondák. Minden detektált szolgáltatóra a szkenner futtatja a szolgáltató-specifikus ellenőrzést: a baas.supabase-rls a PostgREST-et szondázza; a baas.firebase-rules a Firestore-t + RTDB-t + Storage-ot szondázza; a baas.clerk-auth0 a bundle-be ágyazott kulcsok előtagját érvényesíti; a bundle-secrets ellenőrzés érvényesíti, hogy nem szivárogtak service-szintű credentialek. Minden szonda függetlenül fut — egy Supabase-találat nem blokkolja a Firebase-szkennelést.
3. 3. fázis — szolgáltatók közötti korreláció. A szkenner cross-referenceli a találatokat. Egy kiszivárgott Supabase service-role kulcs hiányzó RLS-szel egyszerre súlyosabb, mint bármelyik találat külön — a jelentés felszínre hozza ezt. Több identity-szolgáltató (Clerk + Auth0 + egyedi auth) ugyanabban az alkalmazásban strukturális találat, amit felülvizsgálatra jelölnek.

Minden szonda passzív: legfeljebb egy anonim olvasás erőforrásonként, a válaszforma rögzítve, de a sortartalom soha nem lapozva vagy tárolva. Az írási és módosító szondák ellenőrzött domain-tulajdonjog mögé vannak korlátozva — soha nem futnak nem ellenőrzött célpontok ellen.

Mit talál a szkenner szolgáltatónként

Minden BaaS-szolgáltatónak más a felülete és más a szkennelési stratégiája. Íme, mi van lefedve:

• Supabase: hiányzó RLS táblákon, anonim módon listázható storage bucketök, kiszivárgott service_role JWT vagy sb_secret_* kulcs a bundle-ben, exponált sémák az anonim OpenAPI-listázáson keresztül. Lásd Supabase RLS-szkenner és Storage checklist.
• Firebase: if true szabályok Firestore-on, Realtime Database-en és Cloud Storage-en; anonim módon listázható Storage-bucketök; hiányzó App Check érvényesítés. Lásd Firebase rules szkenner és If-true szabály magyarázat.
• Clerk: bundle-be ágyazott sk_* secret kulcsok, pk_test_* produkcióban, hiányzó webhook-aláírás-ellenőrzés, wildcard engedélyezett origin-ek. Lásd Clerk checklist.
• Auth0: bundle-be ágyazott client secret-ek, engedélyezett Implicit grant, wildcard callback / logout URL-ek, hiányzó PKCE az SPA-kon. Lásd Auth0 checklist.

Hogyan hasonlítható egy BaaS-szkenner az általános DAST- és SAST-eszközökhöz

Egy BaaS-tudatos szkenner specifikus munkát végez, amit más eszközök nem. Az összehasonlítás:

Őszinte scope: mit nem helyettesít ez a szkenner

Egy BaaS-tudatos DAST-szkenner fókuszált eszköz, nem teljes biztonsági program. Nem:

• Nem helyettesíti a SAST-ot vagy SCA-t. A statikus elemzés megtalálja a függőségi CVE-ket (Snyk, Semgrep) és a kód-szintű sebezhetőségeket (SonarQube), amiket egy DAST-szkenner nem tud. Futtasd mindkettőt.
• Nem helyettesíti a manuális penetrációs tesztelést. Egy humán pentester megtalálja az üzleti-logika hibáit, az autorizációs határeseteket és a láncolt sebezhetőségeket, amiket egyetlen szkenner sem tud. Vegyél fel egy pentestert egy nagy launch vagy compliance-audit előtt.
• Nem auditálja a kódodat vagy a repódat secret-ek után a git-történetben. A bundle-secrets ellenőrzés azt fedi le, ami jelenleg deployolva van, nem azt, amit történelmileg commitoltak. Használj git-secrets-et vagy gitleaks-et a repó-higiéniához.
• Nem fedi le a nem BaaS-backend szolgáltatásokat. Ha az alkalmazásod egyedi backendet használ (Express, Rails, Django, FastAPI), a FixVibe szkenneli annak HTTP-felületét, de nem szondázza az adatbázist vagy a mögötte lévő infrastruktúrát. Az az általános DAST + SAST területe.

Gyakori kérdések

Következő lépések

Futtass egy ingyenes FixVibe-szkennelést az éles URL-edre — a BaaS-fázis ellenőrzései minden csomagban benne vannak, az ingyenes csomagot is beleértve. Szolgáltató-specifikus mélymerülésekért az ebben a szakaszban lévő egyes cikkek mindegyik szolgáltatót részletesen lefedik: Supabase RLS, Supabase service-key kitettség, Supabase storage, Firebase rules, Firebase if-true, Clerk és Auth0.