Scanner di configurazioni errate BaaS: trova percorsi di dati pubblici prima degli utenti

Perché le configurazioni errate BaaS hanno una forma ricorrente

Ogni piattaforma BaaS segue la stessa architettura: un backend gestito con un sottile SDK client che parla con esso dal browser. Il client browser-facing ha bisogno di qualche credenziale — una chiave anon, una chiave pubblicabile, un ID progetto Firebase — per identificarsi al backend. Quella credenziale è intenzionalmente pubblica; la sicurezza dell'architettura poggia sul fatto che i controlli di accesso a livello di piattaforma (RLS, regole, allowlist) facciano il loro lavoro.

Gli strumenti di codifica IA costruiscono sopra questa architettura senza interiorizzare lo strato di controlli della piattaforma. Cablano l'SDK client correttamente, accettano le regole permissive di default della piattaforma (che esistono per amichevolezza-tutorial) e spediscono. La forma ricorrente è: credenziale pubblica + regola permissiva di default + override mancante = esposizione di dati. Le cinque classi di configurazione errata sotto sono tutte varianti di questa forma.

Le cinque classi ricorrenti di configurazione errata

Queste appaiono in ogni provider BaaS. Una scansione completa copre tutte e cinque contro ogni provider in uso:

Classe 1: chiave sbagliata nel bundle del browser

Il browser spedisce la chiave secret/admin (Supabase service_role, chiave privata SDK Admin Firebase, Clerk sk_*, client secret Auth0) invece dell'equivalente pubblico/anon. Il browser diventa un client admin senza vincoli. Coperto dalla verifica segreti-nel-bundle di FixVibe.

Classe 2: strato di controllo accessi disabilitato o permissivo

RLS è spento, le regole Firebase sono if true, la lista callback Auth0 ha wildcard. La credenziale nel browser è quella corretta — ma il confine a livello di piattaforma che doveva vincolarla non fa il suo lavoro.

Classe 3: letture anonime di risorse sensibili

Collezioni Firestore leggibili anonimamente, bucket Supabase Storage elencabili anonimamente, API di gestione Auth0 accessibile anonimamente. La scansione chiede: "senza credenziali, cosa posso leggere?"

Classe 4: artefatti di test-mode in produzione

Chiavi di test (pk_test_*, sb_test_*) in un deploy di produzione; app Firebase in dev-mode raggiungibili dal dominio live; applicazioni Auth0 tenant di test con impostazioni più deboli della produzione. La scansione confronta le chiavi runtime contro i prefissi di produzione attesi.

Classe 5: verifica della firma del webhook mancante

I webhook Clerk, Stripe e Supabase firmano tutti i loro payload. Un handler che non verifica la firma è una primitiva di scrittura database per qualsiasi attaccante che indovini l'URL. Rilevato via forma della risposta — una richiesta non firmata che ottiene un 200 significa che la verifica è saltata.

Come funziona la scansione BaaS ombrello FixVibe

La fase BaaS di FixVibe gira in tre stadi, ciascuno produce risultati distinti:

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. Stadio 2 — sondaggi provider-specific. Per ogni provider rilevato, lo scanner esegue il check provider-specific: baas.supabase-rls sonda PostgREST; baas.firebase-rules sonda Firestore + RTDB + Storage; baas.clerk-auth0 valida il prefisso delle chiavi nel bundle; il check segreti-nel-bundle valida che nessuna credenziale di livello servizio sia trapelata. Ogni sondaggio gira indipendentemente — un risultato Supabase non blocca la scansione Firebase.
3. Stadio 3 — correlazione cross-provider. Lo scanner incrocia i risultati. Una chiave di service-role Supabase trapelata accanto a RLS mancante è più grave di uno qualsiasi dei due risultati da solo — il report lo mette in evidenza. Più provider di identità (Clerk + Auth0 + auth personalizzata) nella stessa app è un risultato strutturale segnalato per revisione.

Ogni sondaggio è passivo: al massimo una lettura anonima per risorsa, con la forma della risposta registrata ma il contenuto delle righe mai paginato o memorizzato. I sondaggi di scrittura e modifica sono soggetti a verifica della proprietà del dominio — non vengono mai eseguiti contro target non verificati.

Cosa trova lo scanner per provider

Ogni provider BaaS ha una superficie diversa e una strategia di scansione diversa. Ecco cosa è coperto:

• Supabase: RLS mancante sulle tabelle, bucket di storage elencabili anonimamente, JWT service_role trapelato o chiave sb_secret_* nel bundle, schemi esposti via elenco OpenAPI anonimo. Vedi Scanner RLS Supabase e Checklist Storage.
• Firebase: regole if true su Firestore, Realtime Database e Cloud Storage; bucket Storage elencabili anonimamente; assenza di App Check. Vedi Scanner di regole Firebase e Spiegazione della regola if-true.
• Clerk: chiavi segrete sk_* nel bundle, pk_test_* in produzione, verifica della firma del webhook mancante, origini permesse con wildcard. Vedi Checklist Clerk.
• Auth0: client secret nel bundle, grant Implicit abilitato, URL callback / logout con wildcard, PKCE mancante su SPA. Vedi Checklist Auth0.

Come si confronta uno scanner BaaS con strumenti DAST e SAST generali

Uno scanner consapevole del BaaS fa lavoro specifico che altri strumenti non fanno. Il confronto:

Scope onesto: cosa questo scanner non sostituisce

Uno scanner DAST consapevole del BaaS è uno strumento focalizzato, non un programma di sicurezza completo. Non:

• Sostituisce SAST o SCA. L'analisi statica trova CVE di dipendenze (Snyk, Semgrep) e vulnerabilità a livello di codice (SonarQube) che uno scanner DAST non può. Esegui entrambi.
• Sostituisce penetration test manuali. Un pentester umano trova difetti di logica di business, casi limite di autorizzazione e vulnerabilità concatenate che nessuno scanner può. Assumi un pentester prima di un lancio importante o di un audit di compliance.
• Audita il tuo codice o repo per segreti nella storia git. Il check segreti-nel-bundle copre ciò che è attualmente deployato, non ciò che è stato storicamente committato. Usa git-secrets o gitleaks per l'igiene del repo.
• Copre servizi backend non-BaaS. Se la tua app usa un backend personalizzato (Express, Rails, Django, FastAPI), FixVibe scansiona la sua superficie HTTP ma non sonda il database o l'infrastruttura dietro. Quello è territorio DAST + SAST generale.

Domande frequenti

Prossimi passi

Esegui una scansione FixVibe gratuita contro la tua URL di produzione — i check di fase BaaS sono in ogni piano, inclusa la versione gratuita. Per approfondimenti provider-specific, i singoli articoli di questa sezione coprono ogni provider in dettaglio: RLS Supabase, Esposizione chiave di servizio Supabase, Storage Supabase, Regole Firebase, Firebase if-true, Clerk, e Auth0.