Escáner de configuraciones erróneas de BaaS: encuentra rutas de datos públicas antes que los usuarios

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

Los webhooks de Clerk, Stripe y Supabase firman sus payloads. Un handler que no verifica la firma es una primitiva de escritura en base de datos para cualquier atacante que adivine la URL. Se detecta por la forma de la respuesta — una solicitud sin firmar que recibe un 200 significa que la verificación se ha omitido.

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:

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 — sondeos específicos por proveedor. Para cada proveedor detectado, el escáner ejecuta la verificación específica del proveedor: baas.supabase-rls sondea PostgREST; baas.firebase-rules sondea Firestore + RTDB + Storage; baas.clerk-auth0 valida el prefijo de las claves incrustadas; la verificación de secretos en bundle valida que no se ha filtrado ninguna credencial de nivel de servicio. Cada sondeo se ejecuta independientemente — un hallazgo de Supabase no bloquea el escaneo de Firebase.
3. 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_role filtrado o clave sb_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 true en 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:

Alcance honesto: lo que este escáner no reemplaza

Un escáner DAST consciente de BaaS es una herramienta enfocada, no un programa de seguridad completo. No:

• Reemplaza SAST o SCA. El análisis estático encuentra CVEs en dependencias (Snyk, Semgrep) y vulnerabilidades a nivel de código (SonarQube) que un escáner DAST no puede. Ejecuta ambos.
• Reemplaza las pruebas de penetración manuales. Un pentester humano encuentra fallos de lógica de negocio, casos límite de autorización y vulnerabilidades encadenadas que ningún escáner puede. Contrata un pentester antes de un lanzamiento importante o auditoría de cumplimiento.
• Audita tu código o repo en busca de secretos en el historial git. La verificación de secretos en bundle cubre lo que está desplegado actualmente, no lo que se confirmó históricamente. Usa git-secrets o gitleaks para la higiene del repo.
• Cubre servicios backend no-BaaS. Si tu aplicación usa un backend personalizado (Express, Rails, Django, FastAPI), FixVibe escanea su superficie HTTP pero no sondea la base de datos o infraestructura detrás. Eso es territorio de DAST + SAST general.

Preguntas frecuentes

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.