BaaS-felkonfigurationsscanner: hitta publika datastigar innan användarna gör det

Varför BaaS-felkonfigurationer har en återkommande form

Varje BaaS-plattform följer samma arkitektur: en hanterad backend med ett tunt klient-SDK som pratar med den från webbläsaren. Den webbläsarvända klienten behöver någon credential — en anon-nyckel, en publicerbar nyckel, ett Firebase-projekt-ID — för att identifiera sig mot backenden. Den credentialen är avsiktligt publik; arkitekturens säkerhet vilar på att åtkomstkontroller på plattformsnivå (RLS, rules, allowlists) gör sitt jobb.

AI-kodningsverktyg bygger ovanpå den här arkitekturen utan att internalisera plattformskontroll-lagret. De kopplar upp klient-SDK:t korrekt, accepterar plattformens default-tillåtande regler (som finns för handlednings-vänlighet) och levererar. Den återkommande formen är: publik credential + tillåtande default-regel + saknad åsidosättning = dataexponering. De fem felkonfigurationsklasserna nedan är alla varianter av denna form.

De fem återkommande felkonfigurationsklasserna

Dessa dyker upp över varje BaaS-leverantör. En komplett skanning täcker alla fem mot varje leverantör i bruk:

Klass 1: Fel nyckel i webbläsarbundlen

Webbläsaren levererar secret-/admin-nyckeln (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) istället för den publika/anon-motsvarigheten. Webbläsaren blir en obegränsad admin-klient. Täcks av FixVibes bundle-secrets-check.

Klass 2: Åtkomstkontroll-lager inaktiverat eller tillåtande

RLS är av, Firebase-regler är if true, Auth0-callback-listan är wildcardad. Credentialen i webbläsaren är den korrekta — men plattformsnivå-gränsen som var tänkt att begränsa den gör inte sitt jobb.

Klass 3: Anonyma läsningar av känsliga resurser

Anonymt läsbara Firestore-collections, anonymt listbara Supabase storage-buckets, anonymt åtkomliga Auth0 management API. Skanningen frågar: "utan inloggningsuppgifter, vad kan jag läsa?"

Klass 4: Testlägesartefakter i produktion

Testnycklar (pk_test_*, sb_test_*) i en produktionsdeploy; dev-mode-Firebase-appar nåbara från live-domänen; test-tenant-Auth0-applikationer med svagare inställningar än produktion. Skanningen jämför runtime-nycklarna mot förväntade produktionsprefix.

Klass 5: Saknad webhook-signaturverifiering

Clerk-webhooks, Stripe-webhooks, Supabase-webhooks signerar alla sina payloads. En handler som inte verifierar signaturen är en databasskriv-primitiv för vilken angripare som helst som gissar URL:en. Detekteras via response-form — en osignerad förfrågan som får 200 betyder att verifiering hoppas över.

Hur FixVibes paraply-BaaS-skanning fungerar

FixVibes BaaS-fas körs i tre steg, var och en som producerar distinkta fynd:

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. Steg 2 — leverantörsspecifika sonderingar. För varje upptäckt leverantör kör scannern den leverantörsspecifika checken: baas.supabase-rls sonderar PostgREST; baas.firebase-rules sonderar Firestore + RTDB + Storage; baas.clerk-auth0 validerar prefix för buntade nycklar; bundle-secrets-checken validerar att inga service-tier-credentials har läckt. Varje sondering körs oberoende — ett Supabase-fynd blockerar inte Firebase-skanningen.
3. Steg 3 — leverantörsöverskridande korrelation. Scannern korsrefererar fynd. En läckt Supabase service-role-nyckel jämte saknad RLS är allvarligare än något av fynden ensamt — rapporten lyfter fram det. Flera identitetsleverantörer (Clerk + Auth0 + custom auth) i samma app är ett strukturellt fynd flaggat för granskning.

Varje sondering är passiv: som mest en anonym läsning per resurs, med response-form noterad men radinnehåll aldrig paginerat eller lagrat. Skriv- och modifieringssonderingar är begränsade bakom verifierat domänägarskap — de körs aldrig mot overifierade mål.

Vad scannern hittar per leverantör

Varje BaaS-leverantör har en annan yta och en annan skanningsstrategi. Så här ser täckningen ut:

• Supabase: saknad RLS på tabeller, anonymt listbara storage-buckets, läckt service_role-JWT eller sb_secret_*-nyckel i bundle, exponerade scheman via anonym OpenAPI-listning. Se Supabase RLS-scanner och Storage-checklista.
• Firebase: if true-regler på Firestore, Realtime Database och Cloud Storage; anonymt listbara Storage-buckets; saknad App Check-tillämpning. Se Firebase rules-scanner och If-true-regel förklarad.
• Clerk: buntade sk_*-secret-nycklar, pk_test_* i produktion, saknad webhook-signaturverifiering, wildcard-tillåtna origins. Se Clerk-checklista.
• Auth0: buntade client secrets, Implicit grant aktiverat, wildcard-callback-/logout-URL:er, saknad PKCE på SPA:er. Se Auth0-checklista.

Hur en BaaS-scanner jämförs med generella DAST- och SAST-verktyg

En BaaS-medveten scanner gör specifikt arbete som andra verktyg inte gör. Jämförelsen:

Ärligt omfång: vad den här scannern inte ersätter

En BaaS-medveten DAST-scanner är ett fokuserat verktyg, inte ett komplett säkerhetsprogram. Den:

• Ersätter inte SAST eller SCA. Statisk analys hittar dependency-CVE:er (Snyk, Semgrep) och kodnivå-sårbarheter (SonarQube) som en DAST-scanner inte kan. Kör båda.
• Ersätter inte manuella penetrationstester. En mänsklig pentester hittar logikfel i affärsregler, auktoriserings-edge-cases och kedjade sårbarheter som ingen scanner kan. Hyr in en pentester före en stor lansering eller compliance-granskning.
• Granskar inte din kod eller ditt repo efter hemligheter i git-historik. Bundle-secrets-checken täcker vad som för närvarande är deployat, inte vad som historiskt committats. Använd git-secrets eller gitleaks för repo-hygien.
• Täcker inte icke-BaaS backend-tjänster. Om din app använder en egen backend (Express, Rails, Django, FastAPI), skannar FixVibe dess HTTP-yta men sonderar inte databasen eller infrastrukturen bakom den. Det är territorium för generell DAST + SAST.

Vanliga frågor

Nästa steg

Kör en gratis FixVibe-scanning mot din produktions-URL — BaaS-fas-checkarna ingår i varje plan, inklusive gratisnivån. För leverantörsspecifika fördjupningar täcker de enskilda artiklarna i den här sektionen varje leverantör i detalj: Supabase RLS, Supabase service-nyckel-exponering, Supabase storage, Firebase rules, Firebase if-true, Clerk och Auth0.