BaaS-fejlkonfigurationsscanner: find offentlige datastier, før brugere gør det

Hvorfor BaaS-fejlkonfigurationer har en tilbagevendende form

Hver BaaS-platform følger den samme arkitektur: en administreret backend med en tynd klient-SDK, der taler med den fra browseren. Den browser-vendte klient har brug for en eller anden legitimation — en anon-nøgle, en publicerbar nøgle, et Firebase-projekt-ID — til at identificere sig selv over for backenden. Den legitimation er bevidst offentlig; sikkerheden af arkitekturen hviler på, at platformsniveau-adgangskontroller (RLS, regler, allowlists) gør deres arbejde.

AI-kodeværktøjer bygger oven på denne arkitektur uden at internalisere platformskontrollag-laget. De kobler klient-SDK'en korrekt, accepterer platformens standard-tilladende regler (som eksisterer for tutorial-venlighed) og leverer. Den tilbagevendende form er: offentlig legitimation + tilladende standard-regel + manglende tilsidesættelse = dataeksponering. De fem fejlkonfigurationsklasser nedenfor er alle varianter af denne form.

De fem tilbagevendende fejlkonfigurationsklasser

Disse vises på tværs af hver BaaS-udbyder. En komplet scanning dækker alle fem mod hver udbyder i brug:

Klasse 1: Forkert nøgle i browserbundtet

Browseren sender den hemmelige/admin-nøgle (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) i stedet for den offentlige/anon-ækvivalent. Browseren bliver en ubegrænset admin-klient. Dækket af FixVibes bundle-secrets-check.

Klasse 2: Adgangskontrollag deaktiveret eller tilladende

RLS er slået fra, Firebase-regler er if true, Auth0-callback-listen er wildcardet. Legitimationen i browseren er den rigtige — men platformsniveau-grænsen, der skulle begrænse den, gør ikke sit arbejde.

Klasse 3: Anonyme læsninger af følsomme ressourcer

Anon-læsbare Firestore-samlinger, anon-listbare Supabase storage-buckets, anon-tilgængelige Auth0 management API. Scanningen spørger: "uden legitimationsoplysninger, hvad kan jeg læse?"

Klasse 4: Test-mode-artefakter i produktion

Testnøgler (pk_test_*, sb_test_*) i en produktionsdeploy; dev-mode Firebase-apps tilgængelige fra live-domænet; test-tenant Auth0-applikationer med svagere indstillinger end produktion. Scanningen sammenligner runtime-nøglerne mod de forventede produktionspræfikser.

Klasse 5: Webhook-signaturverifikation mangler

Clerk-webhooks, Stripe-webhooks, Supabase-webhooks signerer alle deres payloads. En handler, der ikke verificerer signaturen, er en database-skrive-primitiv for enhver angriber, der gætter URL'en. Opdages via response-form — en usigneret anmodning, der får et 200, betyder, at verifikation springes over.

Sådan fungerer FixVibes paraply-BaaS-scanning

FixVibes BaaS-fase kører i tre trin, hver der producerer distinkte fund:

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. Trin 2 — udbyder-specifikke sonderinger. For hver opdaget udbyder kører scanneren det udbyder-specifikke check: baas.supabase-rls sonderer PostgREST; baas.firebase-rules sonderer Firestore + RTDB + Storage; baas.clerk-auth0 validerer præfikset på bundlede nøgler; bundle-secrets-checken validerer, at ingen service-tier-legitimationer lækkede. Hver sondering kører uafhængigt — et Supabase-fund blokerer ikke Firebase-scanningen.
3. Trin 3 — krydsudbyderkorrelation. Scanneren krydsrefererer fund. En lækket Supabase service-role-nøgle ved siden af manglende RLS er mere alvorlig end nogen af fundene alene — rapporten overflader dette. Flere identitetsudbydere (Clerk + Auth0 + custom auth) i den samme app er et strukturelt fund markeret til gennemgang.

Hver sondering er passiv: højst én anonym læsning per ressource, med response-form registreret, men rækkeindhold aldrig pagineret eller gemt. Skrive- og modifikationssonderinger er begrænset bag verificeret domæneejerskab — de kører aldrig mod uverificerede mål.

Hvad scanneren finder per udbyder

Hver BaaS-udbyder har en anden overflade og en anden scanningsstrategi. Her er, hvad der er dækket:

• Supabase: manglende RLS på tabeller, anon-listbare storage-buckets, lækket service_role-JWT eller sb_secret_*-nøgle i bundt, eksponerede skemaer via anonym OpenAPI-listning. Se Supabase RLS-scanner og Storage-tjekliste.
• Firebase: if true-regler på Firestore, Realtime Database og Cloud Storage; anon-listbare Storage-buckets; manglende App Check-håndhævelse. Se Firebase-regelscanner og If-true-regel-forklaring.
• Clerk: bundlede sk_*-hemmelige nøgler, pk_test_* i produktion, manglende webhook-signaturverifikation, wildcard-tilladte oprindelser. Se Clerk-tjekliste.
• Auth0: bundlede client secrets, Implicit grant aktiveret, wildcard-callback-/logout-URL'er, manglende PKCE på SPA'er. Se Auth0-tjekliste.

Sådan sammenlignes en BaaS-scanner med generelle DAST- og SAST-værktøjer

En BaaS-bevidst scanner gør specifikt arbejde, som andre værktøjer ikke gør. Sammenligningen:

Ærligt omfang: hvad denne scanner ikke erstatter

En BaaS-bevidst DAST-scanner er et fokuseret værktøj, ikke et fuldt sikkerhedsprogram. Den gør ikke:

• Erstatte SAST eller SCA. Statisk analyse finder afhængigheds-CVE'er (Snyk, Semgrep) og kodeniveau-sårbarheder (SonarQube), som en DAST-scanner ikke kan. Kør begge.
• Erstatte manuel penetrationstest. En menneskelig pentester finder forretningslogik-fejl, autorisations-kanttilfælde og kædede sårbarheder, som ingen scanner kan. Hyr en pentester før en større launch eller compliance-revision.
• Revidere din kode eller repo for hemmeligheder i git-historik. Bundle-secrets-checken dækker, hvad der aktuelt er deployet, ikke hvad der historisk er committet. Brug git-secrets eller gitleaks til repo-hygiejne.
• Dække ikke-BaaS-backend-tjenester. Hvis din app bruger en custom backend (Express, Rails, Django, FastAPI), scanner FixVibe dens HTTP-overflade, men sonderer ikke databasen eller infrastrukturen bag den. Det er generelt DAST + SAST-territorium.

Ofte stillede spørgsmål

Næste skridt

Kør en gratis FixVibe-scanning mod din produktions-URL — BaaS-fase-checks leveres på hver plan, inklusive gratis tier. For udbyder-specifikke deep-dives, dækker de individuelle artikler i dette afsnit hver udbyder i detaljer: Supabase RLS, Supabase service-key-eksponering, Supabase storage, Firebase-regler, Firebase if-true, Clerk og Auth0.