// docs / baas security / umbrella scanner
Escáner de configuraciones erróneas de BaaS: encuentra rutas de datos públicas antes que los usuarios
Los proveedores Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — todos fallan en seguridad de la misma forma: la plataforma incluye valores predeterminados razonables, el desarrollador (o la herramienta de codificación con IA) coge un atajo y se abre una ruta pública entre un atacante no autenticado y los datos de los clientes. Un escáner de configuraciones erróneas de BaaS es la única herramienta que sondea esa ruta desde fuera como lo haría un atacante. Este artículo mapea las cinco clases recurrentes de configuración errónea, explica cómo funciona el escaneo paraguas de BaaS de FixVibe, compara los cuatro proveedores principales y contrasta el escáner consciente de BaaS contra las herramientas DAST generales.
Por qué las configuraciones erróneas de BaaS tienen una forma recurrente
Toda plataforma BaaS sigue la misma arquitectura: un backend gestionado con un SDK cliente fino que habla con él desde el navegador. El cliente de cara al navegador necesita alguna credencial — una clave anon, una clave publicable, un ID de proyecto Firebase — para identificarse ante el backend. Esa credencial es intencionalmente pública; la seguridad de la arquitectura recae en que los controles de acceso a nivel de plataforma (RLS, reglas, listas de permitidos) hagan su trabajo.
Las herramientas de codificación con IA construyen sobre esta arquitectura sin internalizar la capa de controles de la plataforma. Conectan el SDK cliente correctamente, aceptan las reglas permisivas por defecto de la plataforma (que existen para ser amigables con los tutoriales) y publican. La forma recurrente es: credencial pública + regla permisiva por defecto + override ausente = exposición de datos. Las cinco clases de configuración errónea de abajo son todas variantes de esta forma.
Las cinco clases recurrentes de configuración errónea
Aparecen en todos los proveedores BaaS. Un escaneo completo cubre los cinco contra cada proveedor en uso:
Clase 1: Clave incorrecta en el bundle del navegador
El navegador envía la clave secret/admin (Supabase service_role, clave privada del SDK Admin de Firebase, Clerk sk_*, secret de cliente de Auth0) en lugar del equivalente público/anon. El navegador se convierte en un cliente de administrador sin restricciones. Cubierto por la verificación de secretos en bundle de FixVibe.
Clase 2: Capa de control de acceso deshabilitada o permisiva
RLS apagado, reglas Firebase if true, lista de callbacks de Auth0 con comodín. La credencial en el navegador es la correcta — pero el límite a nivel de plataforma que debía constreñirla no está haciendo su trabajo.
Clase 3: Lecturas anónimas de recursos sensibles
Colecciones de Firestore legibles de forma anónima, buckets de Supabase Storage listables anónimamente, API de gestión de Auth0 accesible sin autenticación. El escaneo pregunta: "sin credenciales, ¿qué puedo leer?"
Clase 4: Artefactos de modo prueba en producción
Claves de prueba (pk_test_*, sb_test_*) en un despliegue de producción; aplicaciones Firebase en modo dev accesibles desde el dominio vivo; aplicaciones Auth0 de tenant de prueba con ajustes más débiles que producción. El escaneo compara las claves en tiempo de ejecución contra los prefijos esperados de producción.
Clase 5: Verificación de firma de webhook ausente
Clerk webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
Cómo funciona el escaneo paraguas de BaaS de FixVibe
La fase de BaaS de FixVibe se ejecuta en tres etapas, cada una produciendo hallazgos distintos:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- Etapa 3 — correlación entre proveedores. El escáner cruza los hallazgos. Una clave de rol de servicio filtrada de Supabase junto a RLS faltante es más grave que cualquiera de los dos hallazgos por separado — el reporte lo destaca. Varios proveedores de identidad (Clerk + Auth0 + autenticación personalizada) en la misma aplicación es un hallazgo estructural marcado para revisión.
Cada sondeo es pasivo: como máximo una lectura anónima por recurso, con la forma de la respuesta registrada pero el contenido de las filas nunca paginado o almacenado. Los sondeos de escritura y modificación están restringidos por la verificación de propiedad de dominio — nunca se ejecutan contra objetivos no verificados.
Qué encuentra el escáner por proveedor
Cada proveedor BaaS tiene una superficie diferente y una estrategia de escaneo diferente. Esto es lo que está cubierto:
- Supabase: RLS faltante en tablas, buckets de storage listables anónimamente, JWT
service_rolefiltrado o clavesb_secret_*en bundle, esquemas expuestos vía listado anónimo de OpenAPI. Consulta Escáner de RLS de Supabase y Lista de comprobación de Storage. - Firebase: reglas
if trueen Firestore, Realtime Database y Cloud Storage; buckets de Storage listables anónimamente; ausencia de App Check. Consulta Escáner de reglas de Firebase y Explicación de la regla if-true. - Clerk: claves secretas
sk_*incrustadas,pk_test_*en producción, ausencia de verificación de firma de webhook, orígenes permitidos con comodín. Consulta Lista de comprobación de Clerk. - Auth0: secrets de cliente incrustados, grant Implicit habilitado, URLs de callback / logout con comodín, ausencia de PKCE en SPAs. Consulta Lista de comprobación de Auth0.
Cómo se compara un escáner de BaaS con DAST y SAST generales
Un escáner consciente de BaaS hace un trabajo específico que otras herramientas no. La comparación:
| Aspecto | FixVibe (DAST consciente de BaaS) | DAST general (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| Cobertura de BaaS | Verificaciones nativas para Supabase, Firebase, Clerk, Auth0, Appwrite | Rastreo web genérico; sin sondeos específicos de proveedor | Análisis estático del repo solo; sin validación de producción |
| Tiempo de configuración | URL → run → results usually in under a minute | Horas: configurar spider, autenticación, alcance | Día: integrar en CI del repo |
| Lo que demuestra | Exposición en producción con evidencia a nivel HTTP | Vulns de app web (XSS, SQLi); BaaS vía config manual | Patrones de código que pueden o no llegar a producción |
| Inspección de bundle de JavaScript | Every shipped chunk, with provider-aware key detection | Limitada — solo grep basado en cadenas | Sí, pero solo en el repo, no desplegado |
| Escaneo continuo | Mensual / por despliegue vía API + MCP | Manual; configura tú la programación | Por commit (bueno para código, ciego al runtime) |
| Precio para solo / equipo pequeño | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
Preguntas frecuentes
¿Funciona el escaneo paraguas si mi aplicación usa dos proveedores BaaS (por ej., Supabase + Clerk)?
Sí — la identificación de proveedores y los sondeos por proveedor son independientes. El escáner detecta ambos, ejecuta ambos conjuntos de verificación y reporta correlaciones entre proveedores (por ej., una plantilla JWT de Supabase desde Clerk que envía email como claim junto con RLS faltante).
¿En qué se diferencia esto de ejecutar Burp Suite Pro contra mi aplicación?
Burp es un banco de trabajo DAST general. De serie, Burp no sabe qué es PostgREST, Firestore o la ruta de callback de Auth0 — tienes que configurar manualmente el alcance, escribir extensiones e interpretar respuestas. FixVibe viene con sondeos BaaS incorporados y formato de evidencia con forma BaaS. Burp gana en cobertura general de apps web (XSS, SQLi, lógica de negocio); FixVibe gana en hallazgos específicos de BaaS.
¿Qué hay de App Check (Firebase) o atestación (Apple / Google)?
App Check hace que los escaneos externos oportunistas devuelvan 403 en cada sondeo — el resultado correcto para un bot malicioso. Un escaneo de FixVibe desde un cliente sin atestación se comporta igual. Si tienes App Check habilitado y FixVibe todavía reporta hallazgos, significa que tus reglas están abiertas también para clientes atestados, lo cual es el riesgo real. App Check + reglas correctas es el patrón de defensa en profundidad.
¿Puede el escáner verificar mi corrección?
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
Próximos pasos
Ejecuta un escaneo gratuito de FixVibe contra tu URL de producción — las verificaciones de fase BaaS están en todos los planes, incluido el gratuito. Para profundizaciones específicas por proveedor, los artículos individuales de esta sección cubren cada proveedor en detalle: RLS de Supabase, Exposición de clave de servicio de Supabase, Storage de Supabase, Reglas de Firebase, Firebase if-true, Clerk, y Auth0.