BaaS-virhekonfiguraatioskanneri: löydä julkiset datapolut ennen käyttäjiä

Miksi BaaS-virhekonfiguraatioilla on toistuva muoto

Jokainen BaaS-alusta noudattaa samaa arkkitehtuuria: hallittu backend, johon ohut klientti-SDK puhuu selaimesta. Selaimelle suunnattu klientti tarvitsee jonkin kredentiaalin — anon-avaimen, julkaistavan avaimen, Firebase-projekti-ID:n — tunnistautuakseen backendille. Tuo kredentiaali on tarkoituksellisesti julkinen; arkkitehtuurin turvallisuus lepää siinä, että alustatason pääsynhallinta (RLS, säännöt, allowlistit) tekevät tehtävänsä.

AI-koodaustyökalut rakentavat tämän arkkitehtuurin päälle sisäistämättä alustakontrollikerrosta. Ne johdottavat klientti-SDK:n oikein, hyväksyvät alustan oletussallivat säännöt (jotka ovat olemassa opastusystävällisyyden vuoksi) ja julkaisevat. Toistuva muoto on: julkinen kredentiaali + salliva oletussääntö + puuttuva override = datan paljastuminen. Alla olevat viisi virhekonfiguraatioluokkaa ovat kaikki tämän muodon variantteja.

Viisi toistuvaa virhekonfiguraatioluokkaa

Nämä esiintyvät jokaisen BaaS-tarjoajan yli. Täydellinen skannaus kattaa kaikki viisi jokaista käytössä olevaa tarjoajaa kohti:

Luokka 1: Väärä avain selainpaketissa

Selain lähettää secret-/admin-avaimen (Supabasen service_role, Firebase Admin SDK:n yksityisavain, Clerkin sk_*, Auth0:n klientti-secret) julkisen/anon-vastineen sijasta. Selaimesta tulee rajoittamaton admin-klientti. Kattaa FixVibe-bundle-secrets-tarkistuksen.

Luokka 2: Pääsynhallintakerros poistettu käytöstä tai salliva

RLS on pois päältä, Firebase-säännöt ovat if true, Auth0-callback-lista on wildcard-merkitty. Selaimen kredentiaali on oikea — mutta alustatason raja, jonka oli tarkoitus rajoittaa sitä, ei tee tehtäväänsä.

Luokka 3: Arkaluonteisten resurssien anonyymit luvut

Anonyymisti luettavissa olevat Firestore-collectionit, anonyymisti listattavissa olevat Supabase-storage-bucketit, anonyymisti pääsy Auth0 Management API:in. Skannaus kysyy: "ilman kredentiaaleja, mitä voin lukea?"

Luokka 4: Test-mode-artefaktit tuotannossa

Testiavaimet (pk_test_*, sb_test_*) tuotantojulkaisussa; dev-mode-Firebase-sovellukset tavoitettavissa live-domainista; testi-tenantti-Auth0-sovellukset heikommilla asetuksilla kuin tuotanto. Skannaus vertaa ajonaikaisia avaimia odotettuihin tuotantoetuliitteisiin.

Luokka 5: Webhook-allekirjoituksen verifiointi puuttuu

Clerk-webhookit, Stripe-webhookit, Supabase-webhookit allekirjoittavat kaikki payloadinsa. Käsittelijä, joka ei verifioi allekirjoitusta, on tietokannan kirjoituspr-primitiivi kenelle tahansa hyökkääjälle, joka arvaa URL:n. Havaitaan vastausmuodon kautta — allekirjoittamaton pyyntö, joka saa 200:n, tarkoittaa, että verifiointi on ohitettu.

Miten FixVibe-katto-BaaS-skannaus toimii

FixVibe-BaaS-vaihe ajetaan kolmessa vaiheessa, joista jokainen tuottaa erillisiä löydöksiä:

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. Vaihe 2 — tarjoajakohtaiset tutkimukset. Jokaista havaittua tarjoajaa kohti skanneri ajaa tarjoajakohtaisen tarkistuksen: baas.supabase-rls tutkii PostgRESTia; baas.firebase-rules tutkii Firestoren + RTDB:n + Storagen; baas.clerk-auth0 validoi paketoitujen avainten etuliitteen; bundle-secrets-tarkistus validoi, etteivät palvelutason kredentiaalit ole vuotaneet. Jokainen tutkimus ajetaan itsenäisesti — Supabase-löydös ei blokkaa Firebase-skannausta.
3. Vaihe 3 — tarjoajat ylittävä korrelaatio. Skanneri ristiviittaa löydöksiä. Vuotanut Supabase-service-role-avain yhdessä puuttuvan RLS:n kanssa on vakavampi kuin kumpikaan löydös yksin — raportti nostaa tämän esiin. Useat identiteetin tarjoajat (Clerk + Auth0 + mukautettu auth) samassa sovelluksessa on rakenteellinen löydös, joka liputetaan tarkistettavaksi.

Jokainen tutkimus on passiivinen: korkeintaan yksi anonyymi lukupyyntö resurssia kohti, vastausmuoto tallennettuna, mutta rivien sisältöä ei koskaan sivuuteta tai tallenneta. Kirjoitus- ja muokkaustutkimukset on rajattu vahvistetun domain-omistajuuden taakse — niitä ei koskaan ajeta vahvistamattomia kohteita vastaan.

Mitä skanneri löytää tarjoajaa kohti

Jokaisella BaaS-tarjoajalla on erilainen pinta ja erilainen skannausstrategia. Tässä on, mitä katetaan:

• Supabase: puuttuva RLS tauluissa, anonyymisti listattavissa olevat storage-bucketit, vuotanut service_role-JWT tai sb_secret_*-avain paketissa, paljastuneet skeemat anonyymin OpenAPI-listauksen kautta. Katso Supabase RLS -skanneri ja Storage-tarkistuslista.
• Firebase: if true-säännöt Firestoressa, Realtime Databasessa ja Cloud Storagessa; anonyymisti listattavissa olevat Storage-bucketit; puuttuva App Check -pakotus. Katso Firebase-sääntöskanneri ja If-true-säännön selitys.
• Clerk: paketoidut sk_*-secret-avaimet, pk_test_* tuotannossa, puuttuva webhook-allekirjoituksen verifiointi, wildcard-sallitut originit. Katso Clerk-tarkistuslista.
• Auth0: paketoidut klientti-secretit, Implicit grant käytössä, wildcard-callback-/uloskirjautumis-URL:t, puuttuva PKCE SPA:issa. Katso Auth0-tarkistuslista.

Miten BaaS-skanneri vertautuu yleisiin DAST- ja SAST-työkaluihin

BaaS-tietoinen skanneri tekee spesifistä työtä, jota muut työkalut eivät tee. Vertailu:

Rehellinen laajuus: mitä tämä skanneri ei korvaa

BaaS-tietoinen DAST-skanneri on kohdennettu työkalu, ei täysi tietoturvaohjelma. Se ei:

• Korvaa SASTia tai SCA:ta. Staattinen analyysi löytää riippuvuus-CVE:t (Snyk, Semgrep) ja koodi-tason haavoittuvuudet (SonarQube), joita DAST-skanneri ei voi. Aja molemmat.
• Korvaa manuaalista penetraatiotestausta. Ihmis-pentesteri löytää liiketoimintalogiikan virheet, autorisaation reunatapaukset ja ketjutetut haavoittuvuudet, joita mikään skanneri ei voi. Palkkaa pentesteri ennen suurta lanseerausta tai compliance-auditia.
• Tarkasta koodiasi tai repoasi git-historian salaisuuksien varalta. Bundle-secrets-tarkistus kattaa sen, mikä on tällä hetkellä julkaistu, ei sitä, mikä on historiallisesti committattu. Käytä git-secrets:iä tai gitleaks:iä repon hygieniaan.
• Kata muita kuin BaaS-backend-palveluita. Jos sovelluksesi käyttää mukautettua backendiä (Express, Rails, Django, FastAPI), FixVibe skannaa sen HTTP-pinnan mutta ei tutki sen takana olevaa tietokantaa tai infrastruktuuria. Se on yleisen DAST + SAST -aluetta.

Usein kysytyt kysymykset

Seuraavat askeleet

Aja ilmainen FixVibe-skannaus tuotanto-URL:ääsi vastaan — BaaS-vaiheen tarkistukset tulevat jokaisessa suunnitelmassa, mukaan lukien ilmaistaso. Tarjoajakohtaisiin syväsukelluksiin, tämän osion yksittäiset artikkelit kattavat kunkin tarjoajan yksityiskohtaisesti: Supabase RLS, Supabase service-avaimen paljastuminen, Supabase storage, Firebase-säännöt, Firebase if-true, Clerk, ja Auth0.