Escáner de configuración incorrecta de BaaS: atopa camiños de datos públicos antes que os usuarios

Por que as configuracións incorrectas de BaaS teñen unha forma recorrente

Cada plataforma BaaS segue a mesma arquitectura: un backend xestionado cun SDK cliente fino que fala con el desde o navegador. O cliente orientado ao navegador precisa algunha credencial — unha clave anon, unha clave publicábel, un ID de proxecto Firebase — para identificarse no backend. Esa credencial é intencionalmente pública; a seguranza da arquitectura repousa en que os controis de acceso a nivel de plataforma (RLS, regras, listas permitidas) fagan o seu traballo.

As ferramentas de codificación con IA constrúen sobre esta arquitectura sen interiorizar a capa de controis da plataforma. Conectan o SDK cliente correctamente, aceptan as regras predeterminadas permisivas da plataforma (que existen para amabilidade titorial) e publican. A forma recorrente é: credencial pública + regra predeterminada permisiva + ignorar substitución = exposición de datos. As cinco clases de configuración incorrecta de abaixo son todas variantes desta forma.

As cinco clases de configuración incorrecta recorrentes

Estas aparecen en cada provedor BaaS. Un escaneo completo cobre as cinco en cada provedor en uso:

Clase 1: Clave incorrecta no bundle do navegador

O navegador envía a clave secreta/admin (service_role de Supabase, clave privada do SDK Admin de Firebase, sk_* de Clerk, segredo de cliente de Auth0) no canto da equivalente pública/anon. O navegador convértese nun cliente admin sen restricións. Cuberto pola comprobación de segredos no bundle de FixVibe.

Clase 2: Capa de control de acceso desactivada ou permisiva

RLS está desactivada, as regras de Firebase son if true, a lista de callback de Auth0 ten comodín. A credencial no navegador é a correcta — pero a fronteira a nivel de plataforma que se supuña que a restrinxía non está facendo o seu traballo.

Clase 3: Lecturas anónimas de recursos sensibles

Coleccións Firestore legibles anonimamente, buckets de almacenamento de Supabase listables anonimamente, API de xestión de Auth0 accesible anonimamente. O escaneo pregunta: "sen credenciais, que podo ler?"

Clase 4: Artefactos de modo de proba en produción

Claves de proba (pk_test_*, sb_test_*) nun despregamento de produción; aplicacións Firebase en modo desenvolvemento accesibles desde o dominio en vivo; aplicacións Auth0 de tenant de proba con configuración máis débil que produción. O escaneo compara as claves en tempo de execución cos prefixos de produción esperados.

Clase 5: Verificación de sinatura de webhook ausente

Os webhooks de Clerk, os webhooks de Stripe, os webhooks de Supabase todos asinan as súas cargas útiles. Un manexador que non verifica a sinatura é unha primitiva de escritura na base de datos para calquera atacante que adiviñe o URL. Detectado vía forma da resposta — unha solicitude sen sinatura que recibe un 200 significa que se salta a verificación.

Como funciona o escaneo BaaS global de FixVibe

A fase BaaS de FixVibe execútase en tres etapas, cada unha producindo achados distintos:

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 — sondaxes específicas do provedor. Para cada provedor detectado, o escáner executa a comprobación específica do provedor: baas.supabase-rls sondea PostgREST; baas.firebase-rules sondea Firestore + RTDB + Storage; baas.clerk-auth0 valida o prefixo das claves no bundle; a comprobación de segredos no bundle valida que non se filtraron credenciais de nivel de servizo. Cada sondaxe execútase de xeito independente — un achado de Supabase non bloquea o escaneo de Firebase.
3. Etapa 3 — correlación entre provedores. O escáner correlaciona os achados. Unha clave de rol de servizo de Supabase filtrada xunto con RLS ausente é máis severa que calquera achado por separado — o informe destaca isto. Múltiples provedores de identidade (Clerk + Auth0 + autenticación personalizada) na mesma aplicación é un achado estrutural marcado para revisión.

Cada sondaxe é pasiva: como moito unha lectura anónima por recurso, coa forma da resposta rexistrada pero contidos de fila nunca paxinados nin almacenados. As sondaxes de escritura e modificación requiren propiedade de dominio verificada — nunca se executan contra obxectivos non verificados.

O que atopa o escáner por provedor

Cada provedor BaaS ten unha superficie diferente e unha estratexia de escaneo diferente. Aquí está o que se cobre:

• Supabase: RLS ausente en táboas, buckets de almacenamento listables anonimamente, JWT service_role filtrado ou clave sb_secret_* no bundle, esquemas expostos vía listaxe OpenAPI anónima. Mira Escáner de RLS de Supabase e Lista de almacenamento.
• Firebase: regras if true en Firestore, Realtime Database e Cloud Storage; buckets de Storage listables anonimamente; aplicación de App Check ausente. Mira Escáner de regras de Firebase e Explicación da regra if-true.
• Clerk: claves secretas sk_* no bundle, pk_test_* en produción, verificación de sinatura de webhook ausente, orixes permitidas con comodín. Mira Lista de Clerk.
• Auth0: segredos de cliente no bundle, concesión Implicit activada, URLs de callback / logout con comodín, PKCE ausente en SPAs. Mira Lista de Auth0.

Como se compara un escáner BaaS coas ferramentas DAST e SAST xerais

Un escáner consciente de BaaS fai traballo específico que outras ferramentas non fan. A comparación:

Ámbito honesto: o que este escáner non substitúe

Un escáner DAST consciente de BaaS é unha ferramenta enfocada, non un programa de seguranza completo. Non:

• Substitúe SAST ou SCA. A análise estática atopa CVEs de dependencias (Snyk, Semgrep) e vulnerabilidades a nivel de código (SonarQube) que un escáner DAST non pode. Executa ambos.
• Substitúe as probas manuais de penetración. Un pentester humano atopa fallos de lóxica de negocio, casos límite de autorización e vulnerabilidades encadeadas que ningún escáner pode. Contrata un pentester antes dun lanzamento importante ou unha auditoría de cumprimento.
• Audita o teu código ou repositorio para segredos no historial de git. A comprobación de segredos no bundle cobre o que está actualmente despregado, non o que se confirmou historicamente. Usa git-secrets ou gitleaks para hixiene do repositorio.
• Cobre servizos backend non-BaaS. Se a túa aplicación usa un backend personalizado (Express, Rails, Django, FastAPI), FixVibe escanea a súa superficie HTTP pero non sondea a base de datos ou a infraestrutura detrás dela. Iso é territorio de DAST xeral + SAST.

Preguntas frecuentes

Próximos pasos

Executa un escaneo gratuíto de FixVibe contra o teu URL de produción — as comprobacións de fase BaaS están incluídas en todos os plans, incluído o plan gratuíto. Para inmersións profundas específicas do provedor, os artigos individuais desta sección cobren cada provedor en detalle: RLS de Supabase, Exposición da clave de servizo de Supabase, Almacenamento de Supabase, Regras de Firebase, Firebase if-true, Clerk, e Auth0.