// docs / baas security / umbrella scanner
BaaS-Fehlkonfigurations-Scanner: öffentliche Datenpfade finden, bevor die Nutzer es tun
Backend-as-a-Service-Anbieter — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — scheitern sicherheitstechnisch alle auf dieselbe Weise: die Plattform liefert vernünftige Defaults, der Entwickler (oder das KI-Coding-Tool) greift nach einer Abkürzung, und ein öffentlicher Pfad öffnet sich zwischen einem nicht authentifizierten Angreifer und Kundendaten. Ein BaaS-Fehlkonfigurations-Scanner ist das einzige Tool, das diesen Pfad von außen sondiert, wie ein Angreifer es täte. Dieser Artikel kartiert die fünf wiederkehrenden Fehlkonfigurationsklassen, erklärt, wie der Dach-BaaS-Scan von FixVibe funktioniert, vergleicht die vier Hauptanbieter und kontrastiert den BaaS-bewussten Scanner mit allgemeinen DAST-Tools.
Warum BaaS-Fehlkonfigurationen eine wiederkehrende Form haben
Jede BaaS-Plattform folgt derselben Architektur: ein verwaltetes Backend mit einem schlanken Client-SDK, das aus dem Browser mit ihm spricht. Der browserzugewandte Client braucht irgendein Credential — einen Anon-Key, einen Publishable-Key, eine Firebase-Projekt-ID — um sich gegenüber dem Backend zu identifizieren. Dieses Credential ist absichtlich öffentlich; die Sicherheit der Architektur ruht darauf, dass die Zugriffskontrollen auf Plattform-Ebene (RLS, Rules, Allowlists) ihre Arbeit tun.
KI-Coding-Tools bauen auf dieser Architektur auf, ohne die Plattform-Kontrollen-Ebene zu verinnerlichen. Sie verdrahten das Client-SDK korrekt, akzeptieren die permissiven Default-Regeln der Plattform (die für Tutorial-Freundlichkeit existieren) und liefern aus. Die wiederkehrende Form ist: öffentliches Credential + permissive Default-Regel + fehlendes Override = Datenoffenlegung. Die fünf Fehlkonfigurationsklassen unten sind alles Varianten dieser Form.
Die fünf wiederkehrenden Fehlkonfigurationsklassen
Diese tauchen bei jedem BaaS-Anbieter auf. Ein vollständiger Scan deckt alle fünf gegen jeden verwendeten Anbieter ab:
Klasse 1: Falscher Key im Browser-Bundle
Der Browser liefert den Secret-/Admin-Key (Supabase service_role, Firebase-Admin-SDK-Private-Key, Clerk sk_*, Auth0-Client-Secret) statt des öffentlichen/anon-Äquivalents aus. Der Browser wird zu einem uneingeschränkten Admin-Client. Abgedeckt durch FixVibes Bundle-Secrets-Check.
Klasse 2: Zugriffskontrollebene deaktiviert oder permissiv
RLS ist aus, Firebase-Regeln sind if true, die Auth0-Callback-Liste ist mit Wildcard. Das Credential im Browser ist das richtige — aber die Grenze auf Plattform-Ebene, die es einschränken sollte, tut ihre Arbeit nicht.
Klasse 3: Anonyme Lesezugriffe auf sensible Ressourcen
Anonym lesbare Firestore-Collections, anonym auflistbare Supabase-Storage-Buckets, anonym zugängliche Auth0-Management-API. Der Scan fragt: „ohne Credentials, was kann ich lesen?"
Klasse 4: Test-Mode-Artefakte in Produktion
Test-Keys (pk_test_*, sb_test_*) in einem Produktions-Deploy; Dev-Mode-Firebase-Apps, die aus der Live-Domain erreichbar sind; Test-Tenant-Auth0-Applications mit schwächeren Einstellungen als Produktion. Der Scan vergleicht die Runtime-Keys mit den erwarteten Produktions-Präfixen.
Klasse 5: Webhook-Signatur-Verifizierung fehlt
Clerk-Webhooks, Stripe-Webhooks, Supabase-Webhooks signieren alle ihre Payloads. Ein Handler, der die Signatur nicht verifiziert, ist eine Datenbank-Schreib-Primitive für jeden Angreifer, der die URL errät. Erkannt über die Response-Form — ein unsignierter Request, der 200 bekommt, bedeutet, dass die Verifizierung übersprungen wird.
Wie der Dach-BaaS-Scan von FixVibe funktioniert
Die BaaS-Phase von FixVibe läuft in drei Stufen, jede produziert distinkte Befunde:
- <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.
- Stufe 2 — anbieterspezifische Sondierungen. Für jeden erkannten Anbieter führt der Scanner den anbieterspezifischen Check durch:
baas.supabase-rlssondiert PostgREST;baas.firebase-rulessondiert Firestore + RTDB + Storage;baas.clerk-auth0validiert das Präfix gebündelter Keys; der Bundle-Secrets-Check validiert, dass keine Service-Tier-Credentials geleakt sind. Jede Sondierung läuft unabhängig — ein Supabase-Befund blockiert den Firebase-Scan nicht. - Stufe 3 — Cross-Provider-Korrelation. Der Scanner kreuzt Befunde. Ein geleakter Supabase-Service-Role-Key neben fehlendem RLS ist schwerwiegender als jeder Befund für sich — der Report hebt das hervor. Mehrere Identity-Provider (Clerk + Auth0 + eigene Auth) in derselben App ist ein struktureller Befund, der zur Prüfung markiert wird.
Jede Sondierung ist passiv: höchstens ein anonymer Lesezugriff pro Ressource, mit Response-Form notiert, aber Zeileninhalt nie paginiert oder gespeichert. Schreib- und Modifikations-Sondierungen sind hinter verifizierter Domain-Eigentümerschaft eingegrenzt — sie laufen nie gegen unverifizierte Ziele.
Was der Scanner pro Anbieter findet
Jeder BaaS-Anbieter hat eine andere Oberfläche und eine andere Scan-Strategie. Hier ist, was abgedeckt ist:
- Supabase: fehlendes RLS auf Tabellen, anonym auflistbare Storage-Buckets, geleaktes
service_role-JWT odersb_secret_*-Key im Bundle, exponierte Schemata über anonymes OpenAPI-Listing. Siehe Supabase-RLS-Scanner und Storage-Checkliste. - Firebase:
if true-Regeln auf Firestore, Realtime Database und Cloud Storage; anonym auflistbare Storage-Buckets; fehlendes App-Check-Enforcement. Siehe Firebase-Rules-Scanner und If-true-Regel-Erklärung. - Clerk: gebündelte
sk_*-Secret-Keys,pk_test_*in Produktion, fehlende Webhook-Signatur-Verifizierung, Wildcard-Allowed-Origins. Siehe Clerk-Checkliste. - Auth0: gebündelte Client-Secrets, Implicit-Grant aktiviert, Wildcard-Callback-/Logout-URLs, fehlendes PKCE auf SPAs. Siehe Auth0-Checkliste.
Wie sich ein BaaS-Scanner mit allgemeinen DAST- und SAST-Tools vergleicht
Ein BaaS-bewusster Scanner leistet spezifische Arbeit, die andere Tools nicht tun. Der Vergleich:
| Aspekt | FixVibe (BaaS-bewusstes DAST) | Allgemeines DAST (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| BaaS-Abdeckung | Native Checks für Supabase, Firebase, Clerk, Auth0, Appwrite | Generischer Web-Crawl; keine anbieterspezifischen Sondierungen | Statische Analyse nur des Repos; keine Produktions-Validierung |
| Setup-Zeit | URL → ausführen → Ergebnisse in 60 Sekunden | Stunden: Spider, Auth, Scope konfigurieren | Tag: in Repo-CI integrieren |
| Was es beweist | Produktions-Laufzeit-Offenlegung mit HTTP-Level-Beweis | Web-App-Vulns (XSS, SQLi); BaaS via manueller Konfig | Code-Muster, die deployed werden können oder nicht |
| JavaScript-Bundle-Inspektion | Dekodiert JWTs, matched Secret-Präfixe, läuft durch Chunks | Begrenzt — nur String-basiertes grep | Ja, aber nur Repo-seitig, nicht deployed |
| Kontinuierliches Scannen | Monatlich / bei Deploy via API + MCP | Manuell; Zeitplan selbst konfigurieren | Pro Commit (gut für Code, blind für Runtime) |
| Preis für Solo / kleines Team | Kostenloser Tarif; kostenpflichtig ab $19/Monat | Burp Pro $499/Jahr; ZAP kostenlos, aber hohe Falsch-Positiv-Rate | Snyk kostenlos / Semgrep kostenlos; bezahlte Tiers ab $25/Dev |
Ehrlicher Scope: was dieser Scanner nicht ersetzt
Ein BaaS-bewusster DAST-Scanner ist ein fokussiertes Tool, kein vollständiges Sicherheitsprogramm. Er:
- Ersetzt nicht SAST oder SCA. Statische Analyse findet Abhängigkeits-CVEs (Snyk, Semgrep) und Code-Level-Verwundbarkeiten (SonarQube), die ein DAST-Scanner nicht kann. Setze beides ein.
- Ersetzt nicht manuelle Penetrationstests. Ein menschlicher Pentester findet Geschäftslogik-Schwächen, Autorisierungs-Edge-Cases und verkettete Verwundbarkeiten, die kein Scanner kann. Hire einen Pentester vor einem großen Launch oder Compliance-Audit.
- Auditiert nicht deinen Code oder dein Repo auf Secrets in der Git-Historie. Der Bundle-Secrets-Check deckt ab, was aktuell deployed ist, nicht was historisch committed wurde. Nutze
git-secretsodergitleaksfür Repo-Hygiene. - Deckt keine Nicht-BaaS-Backend-Services ab. Wenn deine App ein eigenes Backend (Express, Rails, Django, FastAPI) verwendet, scannt FixVibe dessen HTTP-Oberfläche, sondiert aber nicht die Datenbank oder Infrastruktur dahinter. Das ist Territorium von allgemeinem DAST + SAST.
Häufig gestellte Fragen
Funktioniert der Dach-Scan, wenn meine App zwei BaaS-Anbieter verwendet (z.B. Supabase + Clerk)?
Ja — Anbieter-Fingerprinting und Per-Provider-Sondierungen sind unabhängig. Der Scanner erkennt beide, führt beide Check-Suites aus und meldet Cross-Provider-Korrelationen (z.B. ein Supabase-JWT-Template aus Clerk, das email als Claim ausliefert, neben fehlendem RLS).
Wie unterscheidet sich das davon, Burp Suite Pro gegen meine App laufen zu lassen?
Burp ist eine allgemeine DAST-Werkbank. Out-of-the-box weiß Burp nicht, was PostgREST, Firestore oder der Auth0-Callback-Pfad ist — du musst Scope manuell konfigurieren, Extensions schreiben und Responses interpretieren. FixVibe kommt mit eingebauten BaaS-Sondierungen und BaaS-förmiger Evidenz-Formatierung. Burp gewinnt bei allgemeiner Web-App-Abdeckung (XSS, SQLi, Geschäftslogik); FixVibe gewinnt bei BaaS-spezifischen Befunden.
Was ist mit App Check (Firebase) oder Attestation (Apple / Google)?
App Check lässt opportunistische externe Scans 403 bei jeder Sondierung zurückgeben — das korrekte Ergebnis für einen böswilligen Bot. Ein FixVibe-Scan von einem nicht attestierten Client verhält sich genauso. Wenn du App Check aktiviert hast und FixVibe immer noch Befunde meldet, bedeutet das, dass deine Regeln auch für attestierte Clients offen sind, was das tatsächliche Risiko ist. App Check + korrekte Regeln ist das Defense-in-Depth-Muster.
Kann der Scanner meinen Fix verifizieren?
Ja — erneut laufen lassen nach Anwendung des Fix. Die Check-IDs (z.B. baas.supabase-rls) sind über Läufe hinweg stabil, also kannst du Befunde diffen: ein Befund, der in Lauf 1 open war und in Lauf 2 fehlt, ist Beweis, dass der Fix gegriffen hat.
Nächste Schritte
Lass einen kostenlosen FixVibe-Scan gegen deine Produktions-URL laufen — die BaaS-Phase-Checks sind in jedem Tarif einschließlich der kostenlosen Stufe. Für anbieterspezifische Vertiefungen behandeln die einzelnen Artikel dieses Abschnitts jeden Anbieter im Detail: Supabase RLS, Supabase-Service-Key-Offenlegung, Supabase Storage, Firebase-Regeln, Firebase if-true, Clerk und Auth0.