ISGroup Consultoría de Ciberseguridad

Supabase, Firebase y Auth0: errores de configuración en aplicaciones creadas con IA

Supabase, Firebase, Auth0 y apps creadas con IA: errores de configuración frecuentes

Supabase, Firebase y Auth0 permiten construir rápidamente lo que un MVP casi siempre requiere: base de datos, inicio de sesión, roles, almacenamiento, API, devoluciones de llamada (callbacks), correo electrónico e integraciones. Al conectarlos a un generador de aplicaciones de IA o a un agente de codificación, el prototipo puede volverse creíble en pocos días. La parte frágil no es el proveedor en sí, sino la configuración que mantiene unidos el frontend generado, el backend gestionado y los datos reales.

El riesgo típico es una aplicación que funciona en la demo pero no separa correctamente usuarios, inquilinos (tenants), roles, buckets, claves y entornos. Las herramientas de IA tienden a resolver el problema inmediato —leer una tabla, hacer que funcione un inicio de sesión, cargar un archivo, cerrar un error CORS, completar un redireccionamiento— sin considerar necesariamente el panorama general. Antes de salir a producción (go-live), es necesario verificar si esas elecciones respetan el principio de menor privilegio, el aislamiento de datos y los controles del lado del servidor.

Este artículo está dirigido a fundadores técnicos, desarrolladores y PM que han utilizado Lovable, Bolt.new, v0, Replit Agent, Cursor, Copilot, Codex, Claude Code u otras herramientas de IA para conectar una aplicación web a Supabase, Firebase o Auth0. La pregunta práctica es: ¿está el backend gestionado configurado para soportar usuarios reales, datos reales y solicitudes directas a las API?

El problema no es usar un BaaS: es usarlo sin límites claros

Los Backend-as-a-Service y los proveedores de identidad son herramientas útiles y maduras. Supabase ofrece base de datos Postgres, Auth, Storage, Edge Functions y controles como Row Level Security (RLS). Firebase ofrece Firestore, Authentication, Cloud Storage, Functions y reglas de seguridad. Auth0 gestiona identidades, inicios de sesión, tokens, callbacks e integraciones con aplicaciones y API.

El punto crítico es la responsabilidad compartida: el proveedor protege la plataforma y ofrece funciones robustas, pero no puede saber si la tabla orders debe ser legible solo por el propietario, si un inquilino no debe ver los archivos de otro, si una callback de entorno de pruebas (staging) debe eliminarse, si una clave de rol de servicio (service role key) terminó en el frontend o si un rol de administrador creado para la demo sigue siendo demasiado potente. Cuando la aplicación es generada con IA, esta distinción se vuelve aún más importante, porque el código puede parecer coherente, la interfaz de usuario puede ocultar acciones no permitidas y las pruebas pueden pasar, pero la seguridad real depende de reglas, políticas, tokens y llamadas directas a la API, no solo del camino visible en la interfaz.

Supabase: RLS no es un detalle opcional

En Supabase, Row Level Security (RLS) es el control central para evitar que diferentes usuarios lean o modifiquen filas no autorizadas. Si una aplicación generada por IA crea tablas, consultas y SDK de cliente sin políticas coherentes, el riesgo es que un usuario autenticado pueda acceder a datos que no le pertenecen.

El caso más peligroso es la tabla expuesta sin RLS o con políticas demasiado permisivas. Una política using (true) puede ser aceptable solo en datos públicos pensados para ser leídos por todos, pero se vuelve crítica en perfiles, pedidos, documentos, espacios de trabajo, mensajes, tickets, facturas o registros multi-inquilino. Incluso las operaciones de insert, update y delete deben tener condiciones coherentes, no solo el select.

Para verificar Supabase no basta con abrir el panel de control y ver que la aplicación funciona. Es necesario crear dos usuarios, dos organizaciones y datos similares, luego probar la lectura, modificación, eliminación y exportación cruzada. Es importante verificar auth.uid(), tenant_id, membresía, rol y propiedad en cada política, verificando también las funciones RPC y las vistas, que pueden convertirse en atajos capaces de eludir el modelo de autorización esperado.

Supabase: anon key, service role key y frontend

La clave anónima (anon key) está diseñada para ser utilizada por el cliente, pero su seguridad depende totalmente de las políticas: si las políticas de RLS y almacenamiento son correctas, la anon key permite solo lo que las políticas permiten. La clave de rol de servicio (service role key) es otra cosa: tiene privilegios elevados y nunca debe terminar en el frontend, en el bundle, en los mapas de origen (source maps), en los registros (logs) o en el repositorio.

Las herramientas de IA pueden confundir este límite. Si una consulta falla por permisos insuficientes, el asistente puede sugerir una solución que utilice una clave más potente o mueva una llamada al lugar equivocado: el resultado funciona, pero elude el modelo de seguridad. Esto sucede a menudo cuando el equipo quiere conectar rápidamente un frontend de React o Next.js a Supabase. Antes del despliegue, es necesario inspeccionar el bundle del frontend, las variables públicas, los archivos .env, los registros de compilación, las funciones serverless y la configuración de la plataforma. Las variables con prefijos del lado del cliente como NEXT_PUBLIC_ deben contener solo valores pensados para el navegador, y cualquier clave de servicio expuesta debe ser rotada.

Supabase Storage: buckets, políticas y archivos privados

Muchas aplicaciones generadas con IA añaden carga de archivos para completar una demo: avatares, documentos, archivos adjuntos, imágenes, PDF, exportaciones, capturas de pantalla o conjuntos de datos. Si Supabase Storage se configura con buckets públicos o políticas abiertas, el inicio de sesión de la aplicación no protege realmente los archivos.

La verificación debe incluir quién puede cargar, leer, descargar, eliminar y sobrescribir archivos. Un usuario no debe poder modificar la ruta o el ID para descargar documentos de otro usuario, y en una aplicación multi-inquilino, cada ruta o metadato debe estar vinculado al inquilino y a la membresía, no solo a un nombre de archivo generado por el cliente. También se debe prestar atención a las vistas previas y a las URL firmadas: un archivo puede ser privado pero tener una vista previa accesible, un enlace con una duración excesiva o metadatos que revelen información sensible. Para archivos no públicos, utiliza buckets privados, políticas por usuario o inquilino, URL firmadas con duración limitada y prueba la descarga con diferentes cuentas.

Firebase: las reglas de seguridad abiertas son el punto más frágil

Firebase hace que sea rápido crear aplicaciones con datos en tiempo real, autenticación y almacenamiento, pero esa velocidad depende de las reglas de seguridad (Security Rules). Firestore y Cloud Storage deben saber quién puede leer, escribir, actualizar y eliminar cada documento o archivo: si las reglas están abiertas para el desarrollo y permanecen así, una aplicación funcional puede exponerlo todo.

Las reglas temporales son frecuentes en proyectos acelerados: allow read, write: if true, controles demasiado genéricos en request.auth != null, condiciones que verifican solo que el usuario esté conectado, comodines de ruta demasiado amplios, ausencia de control sobre el propietario, rol o inquilino. Una interfaz de usuario generada puede mostrar solo los datos correctos, pero las reglas deciden qué sucede cuando alguien llama directamente a Firestore o Storage. Antes de salir a producción, revisa las reglas de Firestore y Cloud Storage por separado, adopta un enfoque de denegación por defecto (default-deny) y abre solo las rutas necesarias. Prueba operaciones con diferentes usuarios, diferentes roles, documentos de otros usuarios, tokens faltantes, tokens caducados y datos fuera de formato. Si la aplicación utiliza Cloud Functions como capa del lado del servidor, verifica que las funciones no reintroduzcan accesos más amplios.

Firebase App Check: útil, pero no sustituye la autenticación ni las autorizaciones

Firebase App Check ayuda a reducir el tráfico de clientes no autorizados o falsificados hacia los servicios de Firebase y backends compatibles, y es útil cuando la aplicación está expuesta y se desea reducir el abuso de API, almacenamiento o funciones. Sin embargo, no decide si un usuario puede leer el documento de otro.

App Check debe tratarse como un control adicional: la autenticación, las reglas de seguridad y las autorizaciones de la aplicación siguen siendo necesarias. Si una regla permite que cualquier usuario conectado lea una colección, App Check no corrige la lógica de acceso, sino que solo limita parte del abuso de clientes no esperados. Para aplicaciones generadas por IA, evalúa App Check cuando tengas un frontend público, cargas de archivos, llamadas frecuentes a servicios de Firebase, funciones serverless o API sensibles. Activa la aplicación donde sea apropiado, supervisa las solicitudes no verificadas y verifica que la aplicación no dependa de App Check para proteger datos que deberían estar protegidos por las reglas.

Auth0: un inicio de sesión exitoso no significa una autorización correcta

Auth0 resuelve una parte importante: autenticar usuarios, gestionar sesiones, emitir tokens e integrar proveedores de identidad. Sin embargo, el inicio de sesión no demuestra que el usuario pueda realizar una acción determinada en la aplicación. Después de la autenticación, el backend debe verificar la audiencia, el emisor, la firma, la caducidad, el alcance (scope), los roles, los permisos, la propiedad y el inquilino.

Un error común en las aplicaciones generadas con IA es usar Auth0 como si el token fuera suficiente para autorizar todo. Si el código solo verifica que exista un usuario conectado, las API y los datos siguen siendo vulnerables a un control de acceso roto (broken access control). Si los roles o las reclamaciones (claims) se interpretan en el lado del frontend sin verificación del lado del servidor, un usuario puede eludir los controles llamando directamente a las API. Antes del despliegue, es necesario verificar qué API aceptan tokens de acceso, qué audiencia se espera, qué alcances se solicitan, cómo se asignan los roles y permisos, y dónde se verifica el token. Cada ruta sensible debe aplicar controles del lado del servidor, no solo renderizado condicional en la interfaz.

Auth0: callbacks, redireccionamientos y dominios de vista previa

Durante el desarrollo con IA, el equipo a menudo añade dominios locales, URL de vista previa, entornos de Vercel, redireccionamientos temporales y callbacks de staging. Auth0 requiere que se configuren las URL de callback permitidas (Allowed Callback URLs), pero si la lista crece sin limpieza, puede volverse demasiado permisiva.

El riesgo es aceptar redireccionamientos o callbacks que ya no son necesarios, dominios de vista previa antiguos, comodines amplios, URL de cierre de sesión incoherentes o orígenes web no alineados con los entornos reales. En los flujos OAuth/OIDC, el redireccionamiento y el estado de la sesión son parte de la seguridad, no solo de la experiencia del usuario. Antes de salir a producción, revisa las URL de callback permitidas, las URL de cierre de sesión permitidas y los orígenes web permitidos: deja solo dominios reales, entornos de staging controlados y URL necesarias, elimina las vistas previas temporales y evita comodines amplios.

Desarrollo, staging y producción: tres entornos, tres perímetros

Los MVP creados con IA a menudo comparten proyectos, bases de datos o claves entre el desarrollo y la producción. Esto simplifica la demo, pero hace que el paso a datos reales sea peligroso: un despliegue de vista previa puede escribir en la base de datos de producción, una prueba puede eliminar datos reales, una clave de staging puede leer archivos de clientes, una callback local puede permanecer activa en producción.

Para Supabase, Firebase y Auth0, separa los entornos con decisión: proyectos diferentes, bases de datos diferentes, almacenamiento diferente, claves diferentes, callbacks diferentes, usuarios de prueba separados y datos sintéticos fuera de la producción. Las políticas deben estar versionadas y controladas por entorno. Esta separación es también un control contra los agentes de IA: si el agente trabaja en un entorno de desarrollo con claves limitadas, un error de configuración tiene un impacto menor; si trabaja con credenciales de producción, cada comando o archivo generado puede convertirse en un incidente.

Probar las políticas: UI, API y SDK

Una configuración de BaaS o Auth no se valida mirando solo la interfaz. Es necesario probar directamente las API, los SDK y las reglas, porque la interfaz de usuario puede impedir una acción mientras que Firestore, Supabase o una API del lado del servidor pueden permitirla de todos modos.

Prepara casos negativos: usuario no conectado, usuario con rol bajo, usuario de otro inquilino, token caducado, ID manipulado, archivo de otro usuario, callback no válida, alcance faltante, audiencia incorrecta, carga fuera de ruta, actualización de campo no permitida. Cada prueba debe demostrar que el dato se deniega en el punto correcto. Para Supabase, prueba consultas del lado del cliente, RPC, almacenamiento y API expuestas; para Firebase, prueba Firestore, almacenamiento y funciones; para Auth0, prueba rutas del lado del servidor, API protegidas, tokens con alcance insuficiente y redireccionamientos. Las pruebas automáticas son útiles, pero para la salida a producción también se necesita una verificación manual orientada al abuso.

Errores frecuentes en aplicaciones Lovable + Supabase

Lovable es un caso recurrente porque permite construir rápidamente aplicaciones full-stack y a menudo se conecta a Supabase. Cuando un MVP generado rápidamente utiliza Supabase como base de datos real sin una revisión de las políticas, el riesgo se concentra en RLS, buckets, claves y consultas generadas para hacer que la demo funcione de inmediato.

Los errores típicos incluyen tablas creadas para hacer funcionar una función sin RLS correcta, buckets utilizados para cargas con políticas amplias, claves de rol de servicio confundidas con claves anónimas, funciones Edge o API que no verifican el inquilino, y consultas que filtran en el lado del frontend en lugar de en la base de datos o en el backend. Antes de conectar datos reales, verifica el esquema generado, las migraciones, las políticas, los buckets, las variables de entorno y las funciones del lado del servidor. Luego prueba con dos usuarios y dos espacios de trabajo: si la aplicación es multi-inquilino, no la publiques hasta que un usuario de un inquilino haya sido bloqueado en el intento de leer datos de otro.

Cuando la IA corrige un error haciendo la configuración más permisiva

Muchas configuraciones incorrectas nacen de una corrección aparentemente razonable. La consulta no devuelve datos, la carga falla, el inicio de sesión vuelve a una página incorrecta, una llamada a la API recibe un 403, una función serverless no lee una tabla. El asistente propone una modificación que desbloquea el flujo —ampliar una política, añadir un dominio, hacer público un bucket, usar una clave más potente, mover una llamada al cliente o simplificar una regla de Firebase— y el arreglo resuelve el síntoma, pero no necesariamente el modelo de seguridad.

Si una política de Supabase se amplía para que pase una pantalla, es necesario verificar qué otros usuarios pueden leer esa tabla. Si una regla de Firebase pasa de un control sobre el propietario a un control sobre el usuario conectado, hay que probar accesos cruzados. Si se añade una callback de Auth0 para una vista previa, debe eliminarse cuando ya no sea necesaria. Si una clave de rol de servicio resuelve un error, la pregunta correcta es por qué la política no permitía la acción correcta. Cada modificación sugerida por la IA sobre políticas, reglas, callbacks, alcances, buckets, CORS, claves de servicio y variables públicas debe tratarse como una modificación sensible: la diferencia puede ser pequeña, pero cambiar un allow read o una callback puede exponer más datos que una refactorización extensa.

Qué corregir antes de salir a producción

Algunos hallazgos en Supabase, Firebase y Auth0 deben bloquear el lanzamiento. RLS ausente en tablas con datos privados, reglas de seguridad abiertas, clave de rol de servicio en el frontend, buckets públicos no previstos, callbacks demasiado permisivas, tokens no verificados del lado del servidor y entornos de staging conectados a datos de producción no son deuda técnica ordinaria: son condiciones que pueden exponer datos tan pronto como la aplicación reciba tráfico real.

La remediación debe ser verificable. Activa o reescribe RLS y luego prueba con diferentes usuarios e inquilinos. Corrige las reglas de Firebase y luego prueba la lectura y escritura directas. Restringe las callbacks de Auth0 y luego verifica el inicio de sesión, el cierre de sesión y los redireccionamientos solo en los entornos previstos. Mueve las claves privadas fuera del frontend y luego verifica los bundles y los registros. Si un bucket pasa de público a privado, verifica también las vistas previas, las URL firmadas y los enlaces compartidos antiguos.

Otras mejoras pueden planificarse después de la salida a producción solo con un riesgo residual claro: documentar mejor las políticas, añadir pruebas automáticas sobre las reglas, reforzar las alertas, separar aún más los roles internos o mejorar la nomenclatura de las variables. Sin embargo, el control mínimo sobre los datos reales debe cerrarse antes de que los usuarios y clientes entren en el sistema.

Cuándo se necesita una verificación independiente

Una revisión interna puede ser suficiente si la aplicación utiliza datos sintéticos, no tiene usuarios externos, no expone cargas de archivos, no tiene roles complejos y el equipo conoce bien Supabase, Firebase o Auth0. En ese caso, el trabajo consiste en verificar RLS, reglas, callbacks y claves antes de que pasen a producción.

En cambio, se necesita una verificación independiente cuando la aplicación trata datos reales, utiliza multi-inquilino, expone API, gestiona archivos, conecta pagos o CRM, utiliza roles administrativos, o cuando la configuración ha sido generada en parte por IA y nadie ha probado las políticas contra el abuso. Lo mismo se aplica si el equipo no sabe distinguir claramente qué es controlado por el proveedor y qué sigue siendo responsabilidad de la aplicación.

Cómo ISGroup puede verificar aplicaciones de IA con Supabase, Firebase y Auth0

ISGroup puede verificar el comportamiento real de la aplicación y las configuraciones que conectan el frontend, el BaaS, el proveedor de identidad, la API y la nube. El objetivo es entender si las reglas protegen realmente los datos cuando el usuario no sigue el flujo previsto por la interfaz de usuario.

Si la aplicación de IA usa… Riesgo principal Control recomendado
Web app, API, flujo de auth, carga o rutas públicas Abuso desde el exterior, BOLA, IDOR, bypass de auth Web Application Penetration Testing
Políticas de Supabase, reglas de Firebase, middleware, consultas o gestión de tokens en el código Lógica de autorización débil o regresiones Code Review
Proyectos BaaS/cloud, buckets, almacenamiento, IAM, claves, entornos y cuentas de servicio Configuración incorrecta o privilegios excesivos Cloud Security Assessment
Servicios, endpoints y componentes expuestos con versiones o configuraciones conocidas Vulnerabilidades conocidas y superficies técnicas expuestas Vulnerability Assessment
Uso continuo de constructores de IA y agentes de codificación en versiones sucesivas Controles no repetibles sobre políticas, auth y despliegue Software Assurance Lifecycle

La elección del control depende de dónde reside el riesgo: comportamiento expuesto, código, políticas, nube, almacenamiento o proceso de lanzamiento. Para aplicaciones que ya están en línea, conviene probar también el comportamiento real, no solo leer las configuraciones.

¿Has conectado una aplicación generada con IA a Supabase, Firebase o Auth0 y necesitas ponerla en línea? ISGroup puede verificar RLS, reglas de seguridad, callbacks, tokens, almacenamiento, API, roles y configuraciones antes de la salida a producción.

Evidencias a preparar

Prepara las URL de los entornos, el repositorio, el proyecto de Supabase/Firebase/Auth0, el esquema de la base de datos, las políticas RLS, las reglas de Firebase, los buckets, las callbacks configuradas, los dominios de vista previa, las variables de entorno, las funciones del lado del servidor, los roles de usuario, los inquilinos, las API y las partes generadas con IA.

También se necesitan cuentas de prueba: usuario anónimo, usuario estándar, usuario administrador y, si corresponde, dos inquilinos o dos espacios de trabajo. Sin cuentas y datos de prueba realistas, se vuelve difícil verificar BOLA, políticas de almacenamiento y callbacks. Si ya has recibido alertas sobre claves expuestas, reglas permisivas, buckets públicos o callbacks no previstas, inclúyelas en la revisión: a menudo, el hallazgo visible es solo el síntoma de un modelo de autorización que debe corregirse.

Lista de verificación antes de salir a producción

  • RLS activa en cada tabla de Supabase con datos no públicos.
  • Políticas de Supabase específicas para select, insert, update y delete.
  • Ninguna clave de rol de servicio en el frontend, en los registros o en el repositorio.
  • Supabase Storage con buckets privados y políticas por usuario o inquilino.
  • Reglas de seguridad de Firestore y reglas de Cloud Storage sin aperturas temporales.
  • Firebase App Check evaluado o activado donde reduce el abuso.
  • Callbacks de Auth0, URL de cierre de sesión y orígenes web en lista blanca sin comodines amplios.
  • Audiencia, alcances, roles y permisos verificados del lado del servidor.
  • Desarrollo, staging y producción separados para proyectos, claves, datos y callbacks.
  • Pruebas manuales con diferentes usuarios, roles e inquilinos en API, SDK, cargas y exportaciones.

Preguntas frecuentes

  • ¿Son Supabase y Firebase seguros por defecto?
  • Son plataformas robustas, pero la seguridad de tu aplicación depende de las RLS, las reglas de seguridad, las políticas de almacenamiento, los roles, las consultas, las claves y las callbacks configuradas en el proyecto.
  • ¿Puede la anon key de Supabase estar en el frontend?
  • Sí, si se utiliza como se espera y si las RLS y las políticas limitan correctamente el acceso. Por el contrario, la clave de rol de servicio nunca debe estar en el frontend.
  • ¿Firebase App Check sustituye la autenticación y la autorización?
  • No. App Check ayuda a verificar que las solicitudes provengan de clientes esperados, pero no decide qué datos puede leer o modificar un usuario.
  • ¿Es suficiente Auth0 para proteger las API?
  • No. Auth0 autentica y emite tokens, pero las API deben verificar el token, la audiencia, el alcance, los roles, la propiedad y el inquilino del lado del servidor.
  • ¿Cuándo se necesita un Web Application Penetration Testing?
  • Cuando la aplicación web, la API, el inicio de sesión, las cargas, las callbacks o las rutas están expuestas en línea. El WAPT verifica el comportamiento real desde el exterior, incluido el abuso de roles y el acceso directo a los endpoints.
  • ¿Qué errores bloquean la salida a producción?
  • RLS ausente en datos privados, reglas de seguridad abiertas, clave de rol de servicio en el frontend, buckets públicos no previstos, callbacks demasiado permisivas, aislamiento de inquilinos no probado, API que solo verifican el inicio de sesión y entornos de producción compartidos con staging.

[Callforaction-WAPT-Footer]

Fuentes y referencias útiles

In

, , , ,