BaaS-feilkonfigurasjonsskanner: finn offentlige datastier før brukerne gjør det

Hvorfor BaaS-feilkonfigurasjoner har en tilbakevendende form

Hver BaaS-plattform følger samme arkitektur: en administrert backend med en tynn klient-SDK som snakker med den fra nettleseren. Den nettleserrettede klienten trenger en eller annen legitimasjon — en anon-nøkkel, en publiserbar nøkkel, en Firebase-prosjekt-ID — for å identifisere seg overfor backenden. Den legitimasjonen er tilsiktet offentlig; arkitekturens sikkerhet hviler på at plattformnivå-tilgangskontroller (RLS, rules, allowlists) gjør jobben sin.

AI-kodeverktøy bygger oppå denne arkitekturen uten å internalisere plattformkontroll-laget. De kobler opp klient-SDK-en korrekt, aksepterer plattformens default-tillatende regler (som finnes for å være vennlig for tutorials), og leverer. Den tilbakevendende formen er: offentlig legitimasjon + tillatende default-regel + manglende overstyring = dataeksponering. De fem feilkonfigurasjonsklassene nedenfor er alle varianter av denne formen.

De fem tilbakevendende feilkonfigurasjonsklassene

Disse dukker opp på tvers av hver BaaS-leverandør. En komplett skanning dekker alle fem mot hver leverandør i bruk:

Klasse 1: Feil nøkkel i nettleserbundlen

Nettleseren leverer hemmelig-/admin-nøkkelen (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) i stedet for den offentlige/anon-ekvivalenten. Nettleseren blir en ubegrenset admin-klient. Dekkes av FixVibes bundle-secrets-sjekk.

Klasse 2: Tilgangskontroll-lag deaktivert eller tillatende

RLS er av, Firebase-regler er if true, Auth0-callback-listen er wildcardet. Legitimasjonen i nettleseren er den riktige — men plattformnivå-grensen som var ment å begrense den, gjør ikke jobben sin.

Klasse 3: Anonyme lesinger av sensitive ressurser

Anon-lesbare Firestore-collections, anon-listbare Supabase storage-buckets, anon-tilgjengelig Auth0 management-API. Skanningen spør: "uten legitimasjon, hva kan jeg lese?"

Klasse 4: Testmodus-artefakter i produksjon

Testnøkler (pk_test_*, sb_test_*) i en produksjonsdeploy; dev-mode-Firebase-apper tilgjengelige fra live-domenet; test-tenant-Auth0-applikasjoner med svakere innstillinger enn produksjon. Skanningen sammenligner runtime-nøklene mot forventede produksjonsprefiks.

Klasse 5: Manglende webhook-signaturverifisering

Clerk-webhooks, Stripe-webhooks, Supabase-webhooks signerer alle sine payloads. En handler som ikke verifiserer signaturen er en database-skriveprimitiv for enhver angriper som gjetter URL-en. Detekteres via response-form — en usignert request som får 200 betyr at verifisering hoppes over.

Hvordan FixVibes paraply-BaaS-skanning fungerer

FixVibes BaaS-fase kjører i tre trinn, hvert produserer distinkte funn:

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. Trinn 2 — leverandørspesifikke sonderinger. For hver oppdaget leverandør kjører skanneren den leverandørspesifikke sjekken: baas.supabase-rls sonderer PostgREST; baas.firebase-rules sonderer Firestore + RTDB + Storage; baas.clerk-auth0 validerer prefiks for bundlede nøkler; bundle-secrets-sjekken validerer at ingen service-tier-legitimasjon har lekket. Hver sondering kjører uavhengig — et Supabase-funn blokkerer ikke Firebase-skanningen.
3. Trinn 3 — leverandøroverskridende korrelasjon. Skanneren krysshenviser funn. En lekket Supabase service-role-nøkkel sammen med manglende RLS er mer alvorlig enn noen av funnene alene — rapporten løfter dette fram. Flere identitetsleverandører (Clerk + Auth0 + egen auth) i samme app er et strukturelt funn flagget for gjennomgang.

Hver sondering er passiv: maksimalt én anonym lesing per ressurs, med response-form notert, men radinnhold aldri paginert eller lagret. Skrive- og modifiseringssonderinger er begrenset bak verifisert domeneierskap — de kjøres aldri mot uverifiserte mål.

Hva skanneren finner per leverandør

Hver BaaS-leverandør har en annen flate og en annen skanningsstrategi. Slik ser dekningen ut:

• Supabase: manglende RLS på tabeller, anon-listbare storage-buckets, lekket service_role-JWT eller sb_secret_*-nøkkel i bundle, eksponerte skjemaer via anonym OpenAPI-listing. Se Supabase RLS-skanner og Storage-sjekkliste.
• Firebase: if true-regler på Firestore, Realtime Database og Cloud Storage; anon-listbare Storage-buckets; manglende App Check-håndheving. Se Firebase rules-skanner og If-true-regel forklart.
• Clerk: bundlede sk_* hemmelig-nøkler, pk_test_* i produksjon, manglende webhook-signaturverifisering, wildcard tillatte origins. Se Clerk-sjekkliste.
• Auth0: bundlede client secrets, Implicit grant aktivert, wildcard callback-/logout-URL-er, manglende PKCE på SPA-er. Se Auth0-sjekkliste.

Hvordan en BaaS-skanner sammenlignes med generelle DAST- og SAST-verktøy

En BaaS-bevisst skanner gjør spesifikt arbeid som andre verktøy ikke gjør. Sammenligningen:

Ærlig omfang: hva denne skanneren ikke erstatter

En BaaS-bevisst DAST-skanner er et fokusert verktøy, ikke et komplett sikkerhetsprogram. Den:

• Erstatter ikke SAST eller SCA. Statisk analyse finner avhengighets-CVE-er (Snyk, Semgrep) og kode-nivå sårbarheter (SonarQube) som en DAST-skanner ikke kan. Kjør begge.
• Erstatter ikke manuell penetrasjonstesting. En menneskelig pentester finner forretningslogikk-feil, autorisasjons-edge-cases og kjedede sårbarheter som ingen skanner kan. Hyr en pentester før en stor lansering eller compliance-gransking.
• Granker ikke koden eller repoet ditt etter hemmeligheter i git-historikk. Bundle-secrets-sjekken dekker det som for øyeblikket er deployet, ikke det som historisk har blitt commitet. Bruk git-secrets eller gitleaks for repo-hygiene.
• Dekker ikke ikke-BaaS backend-tjenester. Hvis appen din bruker en egen backend (Express, Rails, Django, FastAPI), skanner FixVibe HTTP-flaten dens, men sonderer ikke databasen eller infrastrukturen bak den. Det er territorium for generell DAST + SAST.

Ofte stilte spørsmål

Neste steg

Kjør en gratis FixVibe-skanning mot produksjons-URL-en din — BaaS-fase-sjekkene leveres på alle planer, inkludert gratisnivået. For leverandørspesifikke fordypninger dekker de enkelte artiklene i denne seksjonen hver leverandør i detalj: Supabase RLS, Supabase service-nøkkel-eksponering, Supabase storage, Firebase rules, Firebase if-true, Clerk og Auth0.