Seguridad en Base44: qué significa el hallazgo de Wiz para ti

La seguridad en Base44 se volvió un tema público en julio de 2025, cuando investigadores de Wiz descubrieron que un atacante podía registrarse en apps de Base44 que debían ser privadas usando solo el ID de la app. La plataforma, propiedad de Wix, lo corrigió en menos de un día. La falla estaba en la plataforma, no en la app de un dueño en particular, y ya está cerrada.

Eso no significa que tu app sea segura automáticamente. La plataforma protege su infraestructura y las cuentas. Tú eres responsable de quién puede leer qué datos en tu app. Soy un ingeniero brasileño que trabaja con apps construidas con IA, y así es como leería este hallazgo y lo que revisaría.

¿Qué encontraron los investigadores de Wiz en Base44 en julio de 2025?

Los investigadores de Wiz encontraron una brecha de autenticación en Base44. Las apps que debían ser privadas podían ser accedidas por alguien que solo conociera el ID de la app. Con ese ID, un atacante podía registrar una cuenta nueva en la app, aunque el dueño la hubiera configurado como una aplicación cerrada y privada.

Por qué importaba un ID de app

En la mayoría de los sistemas, un ID de app no suele tratarse como un secreto. Identificadores como ese pueden aparecer en URLs, en solicitudes de red o en el código del front-end. Un diseño en el que conocer el ID basta para pasar los controles de registro convierte un identificador semipúblico en una puerta. Por eso los investigadores se lo tomaron en serio.

Lo que no significaba

No significa que las apps de Base44 sean inseguras por naturaleza, ni que todas las apps hayan sido vulneradas. Me baso solo en lo que se informó públicamente: la falla existió y se corrigió. No afirmaría más que eso, y desconfiaría de quien lo haga.

¿Qué tan rápido se corrigió?

Según lo informado públicamente, el problema se corrigió en menos de un día. Para una vulnerabilidad a nivel de plataforma, es una respuesta rápida. La velocidad importa porque cada hora que una falla sigue abierta, más personas podrían encontrarla.

Una corrección rápida no te dice si alguien usó la falla antes de que se cerrara. Lo informado públicamente no dice si alguien usó la falla antes de que se cerrara, así que no asumiría ni una cosa ni la otra. Es una razón para revisar tu propia lista de usuarios, algo que explico más abajo.

¿Es seguro usar Base44 ahora?

El problema específico que encontró Wiz está corregido, así que ese hueco está cerrado. Que tu app sea segura depende de cómo está configurada y de lo que hace.

Yo trataría a Base44, Lovable, Bolt y herramientas similares de la misma forma: son buenas para llegar a un primer borrador que funciona. El código generado por IA debe revisarse como cualquier primer borrador. Que la plataforma sea sólida no hace sólida la lógica dentro de tu app.

Un prototipo con datos de prueba y sin pagos tiene poco riesgo. Una app con datos reales de clientes, inicios de sesión y Stripe es otra cosa. Cuanto más está en juego, más vale una revisión breve.

¿Qué partes de la seguridad maneja Base44 y cuáles son tuyas?

La seguridad es una responsabilidad compartida. La tabla muestra la división que uso cuando se lo explico a fundadores.

El hallazgo de Wiz estaba en las dos primeras filas, así que la plataforma tenía que corregirlo. En mi experiencia, los problemas que suelen importar más en las apps construidas con IA están en las filas de abajo, donde el responsable es el dueño.

¿Qué deberían revisar hoy los dueños de apps en Base44?

No necesitas una auditoría completa para detectar la mayor parte del riesgo. Cuatro revisiones enfocadas cubren casi todo antes de que lleguen usuarios reales.

1. Reglas de acceso a datos

Para cada tipo de dato, pregúntate: ¿un usuario con sesión iniciada puede leer o editar los registros de otro usuario? Pruébalo. Crea dos cuentas e intenta abrir los datos de la segunda desde la primera. En las apps de Lovable, una row level security débil en Supabase ha sido un patrón repetido, y la misma pregunta aplica en cualquier constructor.

2. Claves expuestas

Abre tu app en el navegador, revisa las solicitudes de red y el código fuente de la página, y busca cualquier cosa que parezca una clave secreta. Las claves públicas no son un problema. Las claves secretas de pagos, email o servicios de IA tienen que vivir en un servidor, nunca en el navegador. Si alguna se filtró, rótala.

3. Confirmación de pagos

No confíes en el navegador para saber si un pago se completó. Tu app debe confirmar el pago mediante eventos de Stripe verificados en el servidor. Revisa qué pasa si un evento llega dos veces, llega tarde o nunca llega. Los escáneres genéricos no detectan esto porque es lógica de negocio, no un patrón de vulnerabilidad conocido.

4. Backups

Averigua dónde viven tus datos y si puedes restaurarlos. Un backup que nunca restauraste es una suposición. Exporta una copia de los datos que no te puedes permitir perder.

Revisa también tu lista de usuarios

Por el hallazgo de Wiz, revisa los usuarios registrados en una app privada. Elimina las cuentas que no reconozcas y verifica si alguna tocó datos. Toma minutos y te dice algo concreto.

¿Cuándo deberías salir de Base44?

Quedarse a veces es la mejor decisión, y no empujo a la gente a irse por defecto. Migrar cuesta tiempo y crea sus propios riesgos.

Razones para quedarte

• Estás validando una idea con pocos usuarios y sin datos sensibles.
• La app es simple y puedes pasar las cuatro revisiones dentro del constructor.
• No tienes un ingeniero que mantenga el código que pasaría a ser tuyo después de salir.

Razones para irte

• Necesitas control sobre el hosting, los logs, los backups o dónde se almacenan los datos.
• Tu lógica superó lo que el constructor maneja de forma confiable, como pagos o permisos complejos.
• Clientes o socios piden evidencia de seguridad que no puedes producir en la plataforma.
• El rendimiento con tráfico real se está volviendo un problema.

Si te vas, el orden que prefiero es: corregir primero los problemas de mayor riesgo en el código existente, luego exportar a GitHub y a tu propio hosting, y solo reescribir lo que de verdad esté roto. Una reescritura completa rara vez es el primer paso. Revisa qué opciones de exportación ofrece tu constructor, porque varían entre herramientas. El código de Lovable, por ejemplo, puede ir a GitHub y a tu propio hosting.

¿Quieres una segunda opinión sobre tu app?

Si tienes una app en Base44 que va camino a usuarios reales, escribe a me@filipeeduardo.dev con el enlace y una nota sobre lo que hace, y te diré qué revisaría primero.