Escàner de configuracions errònies de BaaS: troba rutes de dades públiques abans que ho facin els usuaris

Per què les configuracions errònies de BaaS tenen una forma recurrent

Cada plataforma BaaS segueix la mateixa arquitectura: un backend gestionat amb un SDK client prim que hi parla des del navegador. El client de cara al navegador necessita alguna credencial — una clau anon, una clau publicable, un ID de projecte Firebase — per identificar-se al backend. Aquesta credencial és intencionalment pública; la seguretat de l'arquitectura recau en els controls d'accés a nivell de plataforma (RLS, regles, llistes d'autorització) fent la seva feina.

Les eines de codificació amb IA construeixen sobre aquesta arquitectura sense interioritzar la capa de controls de plataforma. Connecten el SDK client correctament, accepten les regles permissives per defecte de la plataforma (que existeixen per ser amables amb els tutorials) i publiquen. La forma recurrent és: credencial pública + regla permissiva per defecte + absència de sobreescriptura = exposició de dades. Les cinc classes de configuració errònia a continuació són totes variants d'aquesta forma.

Les cinc classes de configuració errònia recurrents

Apareixen en tots els proveïdors BaaS. Un escaneig complet cobreix les cinc contra cada proveïdor en ús:

Classe 1: Clau incorrecta al bundle del navegador

El navegador envia la clau secreta/d'administrador (Supabase service_role, clau privada del SDK Admin de Firebase, Clerk sk_*, client secret d'Auth0) en lloc de l'equivalent pública/anon. El navegador es converteix en un client d'administrador sense restriccions. Cobert per la comprovació de secrets en bundle de FixVibe.

Classe 2: Capa de control d'accés deshabilitada o permissiva

RLS està desactivat, les regles de Firebase són if true, la llista de callbacks d'Auth0 té comodins. La credencial al navegador és la correcta — però la frontera de nivell de plataforma que havia de restringir-la no fa la seva feina.

Classe 3: Lectures anònimes de recursos sensibles

Col·leccions de Firestore llegibles anònimament, contenidors d'emmagatzematge de Supabase llistats anònimament, API de gestió d'Auth0 accessible anònimament. L'escaneig pregunta: "sense credencials, què puc llegir?"

Classe 4: Artefactes de mode test a producció

Claus de prova (pk_test_*, sb_test_*) en un desplegament de producció; aplicacions Firebase en mode dev accessibles des del domini real; aplicacions Auth0 de tenant de prova amb configuracions més febles que producció. L'escaneig compara les claus en temps d'execució amb els prefixos de producció esperats.

Classe 5: Verificació de signatura de webhook absent

Els webhooks de Clerk, els webhooks de Stripe i els webhooks de Supabase signen tots els seus payloads. Un handler que no verifica la signatura és una primitiva d'escriptura a la base de dades per a qualsevol atacant que endevini l'URL. Detectat via forma de resposta — una petició no signada que rep un 200 significa que la verificació s'està saltant.

Com funciona l'escaneig global de BaaS de FixVibe

La fase de BaaS de FixVibe s'executa en tres etapes, cadascuna produint troballes diferents:

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. Etapa 2 — sondejos específics del proveïdor. Per a cada proveïdor detectat, l'escàner executa la comprovació específica del proveïdor: baas.supabase-rls sondeja PostgREST; baas.firebase-rules sondeja Firestore + RTDB + Storage; baas.clerk-auth0 valida el prefix de les claus en bundle; la comprovació de secrets en bundle valida que cap credencial de nivell de servei s'hagi filtrat. Cada sondeig s'executa de manera independent — una troballa de Supabase no bloqueja l'escaneig de Firebase.
3. Etapa 3 — correlació entre proveïdors. L'escàner creua referències entre troballes. Una clau de rol de servei de Supabase filtrada al costat d'un RLS absent és més greu que qualsevol de les dues troballes per separat — l'informe ho ressalta. Múltiples proveïdors d'identitat (Clerk + Auth0 + autenticació personalitzada) a la mateixa aplicació és una troballa estructural marcada per a revisió.

Cada sondeig és passiu: com a màxim una lectura anònima per recurs, amb la forma de resposta registrada però el contingut de files mai paginat ni emmagatzemat. Els sondejos d'escriptura i modificació estan restringits per la verificació de propietat de domini — mai s'executen contra objectius no verificats.

Què troba l'escàner per proveïdor

Cada proveïdor BaaS té una superfície diferent i una estratègia d'escaneig diferent. Això és el que cobreix:

• Supabase: RLS absent en taules, contenidors d'emmagatzematge llistats anònimament, JWT service_role o clau sb_secret_* filtrats al bundle, esquemes exposats via llistat OpenAPI anònim. Consulta Escàner de RLS de Supabase i Llista de comprovació d'emmagatzematge.
• Firebase: regles if true a Firestore, Realtime Database i Cloud Storage; contenidors de Storage llistats anònimament; aplicació d'App Check absent. Consulta Escàner de regles de Firebase i Explicació de la regla if-true.
• Clerk: claus secretes sk_* en bundle, pk_test_* a producció, verificació de signatura de webhook absent, orígens permesos amb comodins. Consulta Llista de comprovació de Clerk.
• Auth0: client secrets en bundle, grant Implicit habilitat, URLs de callback / logout amb comodins, PKCE absent a SPAs. Consulta Llista de comprovació d'Auth0.

Com es compara un escàner BaaS amb les eines DAST i SAST generals

Un escàner conscient de BaaS fa una feina específica que altres eines no fan. La comparació:

Abast honest: què no substitueix aquest escàner

Un escàner DAST conscient de BaaS és una eina enfocada, no un programa de seguretat complet. No:

• Substitueix SAST o SCA. L'anàlisi estàtica troba CVEs de dependències (Snyk, Semgrep) i vulnerabilitats a nivell de codi (SonarQube) que un escàner DAST no pot. Executa'ls tots dos.
• Substitueix les proves de penetració manuals. Un pentester humà troba defectes de lògica de negoci, casos límit d'autorització i vulnerabilitats encadenades que cap escàner pot. Contracta un pentester abans d'un llançament important o una auditoria de compliment.
• Audita el teu codi o repositori a la cerca de secrets a l'historial de git. La comprovació de secrets en bundle cobreix el que està desplegat actualment, no el que s'ha confirmat històricament. Fes servir git-secrets o gitleaks per a la higiene del repositori.
• Cobreix serveis de backend no-BaaS. Si la teva aplicació fa servir un backend personalitzat (Express, Rails, Django, FastAPI), FixVibe escaneja la seva superfície HTTP però no sondeja la base de dades ni la infraestructura darrere. Això és territori de DAST general + SAST.

Preguntes freqüents

Següents passos

Executa un escaneig gratuït de FixVibe contra el teu URL de producció — les comprovacions de fase BaaS s'inclouen a tots els plans, inclòs el gratuït. Per a aprofundiments específics per proveïdor, els articles individuals d'aquesta secció cobreixen cada proveïdor en detall: RLS de Supabase, exposició de claus de servei de Supabase, emmagatzematge de Supabase, regles de Firebase, if-true de Firebase, Clerk i Auth0.