BaaS konfigurazio okerren eskanerra: aurkitu datu publikoen bideak erabiltzaileek baino lehen

Zergatik duten BaaS konfigurazio okerrek forma errepikakorra

BaaS plataforma bakoitzak arkitektura bera jarraitzen du: kudeatutako backend bat nabigatzailetik hitz egiten duen bezero-SDK mehe batekin. Nabigatzaileari begira dagoen bezeroak kredentzialen bat behar du — anon gako, gako argitaragarri, Firebase proiektuaren ID — backendari berarekin identifikatzeko. Kredentzial hori nahita publikoa da; arkitekturaren segurtasuna plataforma-mailako sarbide-kontrolen gainean datza (RLS, arauak, baimen-zerrendak) beren lana egiten.

IA kodetze-tresnek arkitektura honen gainean eraikitzen dute plataforma-kontrolen geruza barneratu gabe. Bezero-SDK-a behar bezala konektatzen dute, plataformaren lehenetsiko arau permisiboak (tutoriala lagungarriak izateagatik daudenak) onartzen dituzte eta bidaltzen dute. Forma errepikakorra hau da: kredentzial publikoa + lehenetsiko arau permisiboa + ezarpen falta = datu-agerpena. Beheko bost konfigurazio oker klaseak forma honen aldaerak dira guztiak.

Bost konfigurazio oker klase errepikakorrak

Hauek BaaS hornitzaile bakoitzean agertzen dira. Eskaneatze osoak erabiltzen den hornitzaile bakoitzaren aurka bost guztiak biltzen ditu:

1. klasea: Okerreko gakoa nabigatzaileko bundle-an

Nabigatzaileak gako sekretua/administratzailearena (Supabase service_role, Firebase Admin SDK gako pribatua, Clerk sk_*, Auth0 bezero-sekretua) bidaltzen du publikoa/anon-aren ordez. Nabigatzailea mugatu gabeko admin bezero bat bihurtzen da. FixVibe-ren bundle-secrets egiaztapenak estaltzen du.

2. klasea: Sarbide-kontrol geruza desgaituta edo permisiboa

RLS itzalita dago, Firebase arauak if true dira, Auth0 callback zerrenda komodineko. Nabigatzaileko kredentziala zuzena da — baina hura mugatu behar zuen plataforma-mailako muga ez du bere lana egiten.

3. klasea: Baliabide sentikorren irakurketa anonimoak

Anon-irakurgarri Firestore bildumak, anon-zerrendagarri Supabase biltegiratze-ontziak, anon-sarbide Auth0 management API. Eskaneatzeak galdetzen du: "kredentzialik gabe, zer irakur dezaket?"

4. klasea: Test-mode artefaktuak ekoizpenean

Proba-gakoak (pk_test_*, sb_test_*) ekoizpen-zabalpen batean; dev-mode Firebase aplikazioak domeinu zuzentik iristerrazak; ekoizpenarena baino ezarpen ahulagoak dituzten Auth0 proba-maizterren aplikazioak. Eskaneatzeak exekuzio-gakoak ekoizpenerako espero diren aurrizkien aurka konparatzen ditu.

5. klasea: Webhook sinaduraren egiaztapena falta

Clerk webhook-ek, Stripe webhook-ek, Supabase webhook-ek karga-erabilgarriak sinatzen dituzte. Sinadura egiaztatzen ez duen kudeatzaile bat datu-baseko idazketa primitibo bat da URLa asmatzen duen edozein erasotzailerentzat. Erantzunaren formaren bidez detektatzen da — 200 jasotzen duen sinatu gabeko eskaera batek esan nahi du egiaztapena saltatzen dela.

Nola funtzionatzen duen FixVibe-ren BaaS eskaneatze aterkiak

FixVibe-ren BaaS fasea hiru etapatan exekutatzen da, bakoitzak aurkikuntza bereiziak sortuz:

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. 2. etapa — hornitzaileari berariazko frogak. Detektatutako hornitzaile bakoitzeko, eskanerrak hornitzaileari berariazko egiaztapena exekutatzen du: baas.supabase-rls-k PostgREST miatzen du; baas.firebase-rules-k Firestore + RTDB + Storage miatzen du; baas.clerk-auth0-k bundle-eko gakoen aurrizkia balioztatzen du; bundle-secrets egiaztapenak ez direla zerbitzu-mailako kredentzialik iragazi baliozkotzen du. Froga bakoitza independenteki exekutatzen da — Supabase aurkikuntza batek ez du Firebase eskaneatzea blokeatzen.
3. 3. etapa — hornitzaileen arteko korrelazioa. Eskanerrak aurkikuntzak gurutzatzen ditu. Galdutako Supabase service-role gako bat RLS falta dela RLSrekin baino larriagoa da bi aurkikuntzak banaka baino — txostenak hori ateratzen du. Aplikazio berean identitate-hornitzaile anitz (Clerk + Auth0 + autentifikazio pertsonalizatua) berrikusteko markatzen den egiturazko aurkikuntza da.

Froga bakoitza pasiboa da: gehienez ere baliabide bakoitzeko irakurketa anonimo bat, erantzunaren forma grabatuta baina errenkaden edukia inoiz orrikatu edo gorde gabe. Idazketa eta aldatze-frogak egiaztatutako domeinu-jabetzaren atzean daude — ez dira inoiz egiaztatu gabeko helburuen aurka exekutatzen.

Eskanerrak hornitzaile bakoitzeko zer aurkitzen duen

BaaS hornitzaile bakoitzak azalera desberdina eta eskaneatze-estrategia desberdina ditu. Hau biltzen denaren laburpena:

• Supabase: tauletan RLS falta, anon-zerrendagarri biltegiratze-ontziak, bundle-an galdutako service_role JWT edo sb_secret_* gakoa, anonimoko OpenAPI zerrendatzearen bidez agerian dauden eskemak. Ikus Supabase RLS eskanerra eta Biltegiratze-zerrenda.
• Firebase: if true arauak Firestore, Realtime Database eta Cloud Storage-en; anon-zerrendagarri Storage ontziak; App Check-eko betearazpena falta. Ikus Firebase arauen eskanerra eta If-true arauaren azalpena.
• Clerk: bundle-eko sk_* gako sekretuak, ekoizpenean dagoen pk_test_*, webhook sinaduraren egiaztapena falta, komodineko baimendutako jatorriak. Ikus Clerk zerrenda.
• Auth0: bundle-eko bezero-sekretuak, gaitutako Implicit hornidura, komodineko callback / itxiera URLak, SPA-etan PKCE falta. Ikus Auth0 zerrenda.

BaaS eskaner batek DAST eta SAST tresna orokorrekin nola alderatzen den

BaaS-aware eskaner batek beste tresnek egiten ez duten lan zehatza egiten du. Alderaketa:

Esparru zintzoa: zer ez duen ordezten eskaner honek

BaaS-aware DAST eskaner bat tresna zentratu bat da, ez segurtasun-programa osoa. Ez du:

• SAST edo SCA ordezten. Analisi estatikoak menpekotasun CVEak (Snyk, Semgrep) eta kode-mailako ahultasunak (SonarQube) aurkitzen ditu DAST eskaner batek ezin dituenak. Bi exekutatu.
• Eskuzko sartzeko probak ordezten. Pentester gizaki batek negozio-logikako akatsak, baimen-mugen kasuak eta kateatutako ahultasunak aurkitzen ditu eskaner batek ezin dituenak. Kontratatu pentester bat jaurtipen handi baten edo betetze-auditoretza baten aurretik.
• Auditatu zure kodea edo biltegia git historian dauden sekretuengatik. Bundle-secrets egiaztapenak orain zabaldutakoa estaltzen du, ez historikoki konpromisoa hartu zena. Erabili git-secrets edo gitleaks biltegiaren higienerako.
• BaaS ez diren backend zerbitzuak estaltzen. Zure aplikazioak backend pertsonalizatu bat erabiltzen badu (Express, Rails, Django, FastAPI), FixVibe-k bere HTTP azalera eskaneatzen du baina ez du datu-basea edo atzean dagoen azpiegitura miatzen. Hori DAST + SAST orokorraren lurraldea da.

Maiz egiten diren galderak

Hurrengo urratsak

Egin FixVibe eskaneatze doako bat zure ekoizpen-URLaren aurka — BaaS-faseko egiaztapenak plan guztietan bidaltzen dira, doako maila barne. Hornitzaile-bakoitzeko sakontasun-azterketetarako, atal honetako artikulu indibidualek hornitzaile bakoitza xehetasunez biltzen dute: Supabase RLS, Supabase service-key agerpena, Supabase biltegiratzea, Firebase arauak, Firebase if-true, Clerk eta Auth0.