// docs / baas security / umbrella scanner
Skener BaaS pogrešnih konfiguracija: pronađite javne data putanje prije korisnika
Backend-as-a-Service provideri — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — svi ne uspijevaju u sigurnosti u istom obliku: platforma isporučuje razumne defaulte, developer (ili AI alat za kodiranje) poseže za prečicom, i javni put se otvara između neautenticiranog napadača i korisničkih podataka. Skener BaaS pogrešnih konfiguracija je jedini alat koji ispituje taj put izvana onako kako bi to učinio napadač. Ovaj članak mapira pet ponavljajućih klasa pogrešnih konfiguracija, objašnjava kako radi umbrella FixVibe BaaS sken, poredi četiri glavna providera i kontrastira BaaS-svjesni skener u odnosu na opće DAST alate.
Zašto BaaS pogrešne konfiguracije imaju ponavljajući oblik
Svaka BaaS platforma slijedi istu arhitekturu: upravljani backend s tankim klijentskim SDK-om koji s njim razgovara iz preglednika. Klijent okrenut pregledniku treba neki akreditiv — anon ključ, publishable ključ, Firebase project ID — da bi se identificirao backendu. Taj akreditiv je namjerno javan; sigurnost arhitekture počiva na tome da kontrolama pristupa na nivou platforme (RLS, pravila, allowlist-e) rade svoj posao.
AI alati za kodiranje grade povrh ove arhitekture bez internalizovanja sloja platforme-kontrola. Žice klijentski SDK ispravno, prihvataju platformine default permisivna pravila (koja postoje zbog prijateljskog tutorijala) i isporučuju. Ponavljajući oblik je: javni akreditiv + permisivno default pravilo + nedostajući override = izlaganje podataka. Pet klasa pogrešnih konfiguracija u nastavku su sve varijante ovog oblika.
Pet ponavljajućih klasa pogrešnih konfiguracija
Ove se pojavljuju u svim BaaS providerima. Potpun sken pokriva svih pet u odnosu na svakog providera u upotrebi:
Klasa 1: Pogrešan ključ u bundleu preglednika
Preglednik isporučuje tajni/admin ključ (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) umjesto javnog/anon ekvivalenta. Preglednik postaje neograničen admin klijent. Pokriveno FixVibe-ovom provjerom bundle-secrets.
Klasa 2: Sloj kontrole pristupa onemogućen ili permisivan
RLS je isključen, Firebase pravila su if true, Auth0 callback lista ima wildcard. Akreditiv u pregledniku je ispravan — ali granica na nivou platforme koja je trebala da ga ograniči ne radi svoj posao.
Klasa 3: Anonimna čitanja osjetljivih resursa
Anon-čitljive Firestore kolekcije, anon-listable Supabase storage bucketi, anon-dostupan Auth0 management API. Sken pita: "bez akreditiva, šta mogu pročitati?"
Klasa 4: Artefakti test-modea u produkciji
Test ključevi (pk_test_*, sb_test_*) u produkcijskom deploy-u; dev-mode Firebase aplikacije dostupne s live domene; test-tenant Auth0 aplikacije sa slabijim postavkama od produkcije. Sken poredi runtime ključeve u odnosu na očekivane produkcijske prefikse.
Klasa 5: Nedostaje verifikacija potpisa webhooka
Clerk webhookovi, Stripe webhookovi, Supabase webhookovi svi potpisuju svoje payloadove. Handler koji ne verifikuje potpis je primitiva za pisanje u bazi za svakog napadača koji pogodi URL. Detektuje se preko oblika odgovora — nepotpisan zahtjev koji dobije 200 znači da je verifikacija preskočena.
Kako radi umbrella FixVibe BaaS sken
FixVibe-ova BaaS faza radi u tri stadijuma, svaki proizvodi različite nalaze:
- <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.
- Stadijum 2 — probe specifične za providera. Za svaki detektovan provider, skener pokreće provjeru specifičnu za providera:
baas.supabase-rlsispituje PostgREST;baas.firebase-rulesispituje Firestore + RTDB + Storage;baas.clerk-auth0validira prefiks bundled ključeva; provjera bundle-secrets validira da nije procurio nijedan akreditiv service-tier-a. Svaka proba radi nezavisno — Supabase nalaz ne blokira Firebase sken. - Stadijum 3 — međusobna korelacija providera. Skener međusobno upoređuje nalaze. Procurjeli Supabase service-role ključ zajedno s nedostajućim RLS-om je ozbiljniji od bilo kojeg od ova dva nalaza pojedinačno — izvještaj to ističe. Više identity providera (Clerk + Auth0 + custom auth) u istoj aplikaciji je strukturni nalaz označen za pregled.
Svaka proba je pasivna: najviše jedno anonimno čitanje po resursu, s oblikom odgovora zabilježenim ali sadržajem redova nikada paginiranim niti sačuvanim. Probe pisanja i modifikacije uvjetovane su verificiranim vlasništvom domene — nikada se ne pokreću prema neverificiranim ciljevima.
Šta skener pronalazi po provideru
Svaki BaaS provider ima drugačiju površinu i drugačiju strategiju skeniranja. Evo šta je pokriveno:
- Supabase: nedostajući RLS na tabelama, anon-listable storage buckeri, procurjeli
service_roleJWT ilisb_secret_*ključ u bundleu, izloženje sheme preko anonimnog OpenAPI listanja. Pogledajte Supabase RLS skener i Storage checklistu. - Firebase: pravila
if trueu Firestoreu, Realtime Databaseu i Cloud Storageu; anon-listable Storage bucketi; nedostaje primjena App Checka. Pogledajte Skener Firebase pravila i Objašnjenje if-true pravila. - Clerk: bundled
sk_*tajni ključevi,pk_test_*u produkciji, nedostaje verifikacija potpisa webhooka, wildcard dozvoljeni origini. Pogledajte Clerk checklistu. - Auth0: bundled client secreti, Implicit grant omogućen, wildcard callback / logout URL-ovi, nedostaje PKCE na SPA-ovima. Pogledajte Auth0 checklistu.
Kako se BaaS skener poredi s općim DAST i SAST alatima
BaaS-svjestan skener radi specifičan posao koji drugi alati ne rade. Poređenje:
| Aspekt | FixVibe (BaaS-svjestan DAST) | Opći DAST (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| BaaS pokrivenost | Nativne provjere za Supabase, Firebase, Clerk, Auth0, Appwrite | Generički web crawl; bez proba specifičnih za providera | Statička analiza samo repoa; bez produkcijske validacije |
| Vrijeme postavljanja | URL → pokretanje → rezultati u 60 sekundi | Sati: konfigurisati spider, auth, scope | Dan: integrisati u repo CI |
| Šta dokazuje | Izloženost u produkcijskom runtimeu s HTTP-nivo dokazom | Web-app ranjivosti (XSS, SQLi); BaaS preko ručne konfiguracije | Obrasci u kodu koji se mogu i ne moraju deploy-ati |
| Inspekcija JavaScript bundlea | Dekodira JWT-ove, hvata tajne prefikse, prolazi kroz chunkove | Ograničeno — samo grep zasnovan na stringovima | Da, ali samo na strani repoa, ne deploy-ano |
| Kontinuirano skeniranje | Mjesečno / pri deploy-u preko API + MCP | Ručno; sami konfigurišite raspored | Po commitu (dobro za kod, slijepo za runtime) |
| Cijena za solo / mali tim | Besplatni paket; plaćeni od 19 USD/mj | Burp Pro 499 USD/god; ZAP besplatan ali s mnogo lažnih pozitiva | Snyk besplatan / Semgrep besplatan; plaćeni paketi od 25 USD/dev |
Iskren opseg: šta ovaj skener ne zamjenjuje
BaaS-svjestan DAST skener je fokusiran alat, ne potpun sigurnosni program. Ne:
- Zamjenjuje SAST ili SCA. Statička analiza pronalazi dependency CVE-ove (Snyk, Semgrep) i ranjivosti na nivou koda (SonarQube) koje DAST skener ne može. Pokrenite oba.
- Zamjenjuje ručno penetraciono testiranje. Ljudski pentester pronalazi propuste u poslovnoj logici, ivične slučajeve autorizacije i ulančane ranjivosti koje nijedan skener ne može. Unajmite pentestera prije velikog lansiranja ili audita usklađenosti.
- Auditira vaš kod ili repo za tajne u git historiji. Provjera bundle-secrets pokriva ono što je trenutno deploy-ano, ne ono što je historijski commitano. Koristite
git-secretsiligitleaksza higijenu repoa. - Pokriva non-BaaS backend servise. Ako vaša aplikacija koristi prilagođeni backend (Express, Rails, Django, FastAPI), FixVibe skenira njegovu HTTP površinu, ali ne ispituje bazu podataka ili infrastrukturu iza nje. To je teritorij općeg DAST-a + SAST-a.
Često postavljana pitanja
Da li umbrella sken radi ako moja aplikacija koristi dva BaaS providera (npr. Supabase + Clerk)?
Da — fingerprintiranje providera i probe po providerima su nezavisne. Skener detektuje oba, pokreće oba paketa provjera i prijavljuje korelacije između providera (npr. Supabase JWT template iz Clerka koji šalje email kao claim uz nedostajući RLS).
Kako se ovo razlikuje od pokretanja Burp Suite Pro protiv moje aplikacije?
Burp je opća DAST radna ploča. Iz kutije, Burp ne zna šta je PostgREST, Firestore ili Auth0 callback putanja — morate ručno konfigurisati opseg, pisati ekstenzije i tumačiti odgovore. FixVibe se isporučuje s ugrađenim BaaS probama i BaaS-oblikovanim formatiranjem dokaza. Burp pobjeđuje u općoj pokrivenosti web aplikacija (XSS, SQLi, poslovna logika); FixVibe pobjeđuje u BaaS-specifičnim nalazima.
Šta je s App Checkom (Firebase) ili atestacijom (Apple / Google)?
App Check čini da oportunistički eksterni skenovi vrate 403 na svakoj probi — ispravan ishod za zlonamjernog bota. FixVibe sken iz neatestovanog klijenta ponaša se isto. Ako imate uključen App Check i FixVibe i dalje prijavljuje nalaze, to znači da su vaša pravila otvorena i za atestovane klijente, što je stvarni rizik. App Check + ispravna pravila je obrazac dubinske odbrane.
Može li skener verifikovati moj popravak?
Da — pokrenite ponovo nakon primjene popravka. ID-ovi provjera (npr. baas.supabase-rls) stabilni su između pokretanja, pa možete uporediti nalaze: nalaz koji je bio open u pokretanju 1 i odsutan u pokretanju 2 dokaz je da je popravak primijenjen.
Sljedeći koraci
Pokrenite besplatan FixVibe sken prema svom produkcijskom URL-u — provjere BaaS faze isporučuju se u svakom paketu, uključujući i besplatni. Za pojedinačne deep-dive-ove po provideru, pojedinačni članci u ovom odjeljku detaljno pokrivaju svakog providera: Supabase RLS, Izloženost Supabase service-key-a, Supabase storage, Firebase pravila, Firebase if-true, Clerk i Auth0.