Seguridad en el vibe coding: los riesgos que dejan las herramientas de IA

La seguridad en el vibe coding se trata sobre todo de un pequeño conjunto de fallas recurrentes que dejan las herramientas de IA: reglas débiles sobre quién puede leer qué datos, claves secretas que terminan en el navegador y lógica de pago que confía en la señal equivocada. La app suele funcionar en una demo, y justamente por eso estas fallas pasan desapercibidas.

Soy ingeniero sénior y trato el código generado por IA como un primer borrador. Un borrador puede ser bueno, pero alguien que entienda los riesgos tiene que leerlo antes de que lleguen usuarios y pagos reales. Este artículo cubre lo que reviso primero y lo que puedes revisar tú mismo.

¿Cuáles son los riesgos de seguridad más comunes en las apps hechas con vibe coding?

En las apps construidas con IA que reviso, los mismos tipos de problemas tienden a repetirse. No son exóticos; son lo básico que una demo nunca pone a prueba.

• Reglas débiles de acceso a datos. Cualquier usuario con sesión iniciada, o incluso un visitante anónimo, puede leer o editar filas que pertenecen a otras personas.
• Secretos en el navegador. Claves de API o credenciales de servicios incluidas en el código del frontend.
• Pagos confirmados por el cliente. La app marca un pedido como pagado porque el navegador lo dijo, no porque el proveedor de pagos lo confirmó.
• Falta de backups. Nadie ha probado restaurar la base de datos.
• Sin límites. Sin rate limiting, sin validación de entradas en el servidor, sin controles en la carga de archivos.

Cuatro revisiones cubren la mayor parte del riesgo antes de los usuarios reales: reglas de acceso a datos, claves expuestas, confirmación de pagos y backups. No necesitas una auditoría completa para encontrar los peores problemas. Bastan unas pocas revisiones enfocadas, y corregir las cosas es más barato antes de que lleguen usuarios y pagos reales.

¿Por qué las herramientas de IA se equivocan con las reglas de datos?

Un constructor de apps con IA optimiza para que una funcionalidad funcione cuando haces clic en ella. Si pides una página que liste las facturas de un usuario, hace que la página funcione. Que la base de datos se niegue a devolver las facturas de otra persona es otra cuestión, y nadie la planteó.

En Supabase, esa negativa es la row level security. Si la RLS está desactivada, o si una política dice algo como “permitir que todos los usuarios autenticados lean”, el frontend puede seguir viéndose correcto mientras los datos están abiertos. Las apps construidas con Lovable han mostrado un patrón de reglas de RLS débiles, así que esto es lo primero que reviso.

Una revisión rápida que puedes hacer tú mismo

1. Crea dos cuentas de prueba.
2. Con la cuenta A, crea algunos datos.
3. Con la cuenta B, intenta obtener las filas de la cuenta A usando las herramientas de desarrollo del navegador o la API directamente, no la interfaz de la app.
4. Repite sin haber iniciado sesión.

Si la cuenta B o un visitante anónimo ve algo, tus reglas están mal. Busca también tablas con la RLS desactivada y políticas que siempre se evalúan como verdaderas. Ocultar un botón en la interfaz no es una regla; la base de datos debe hacerla cumplir.

¿Cómo terminan las claves secretas en el navegador?

Las apps generadas suelen llamar a servicios de terceros directamente desde el frontend porque es el camino más corto para que una funcionalidad funcione. El modelo necesita una clave para hacer la llamada, así que la clave termina en el código del cliente o en una variable de entorno que la herramienta de build incluye en la página.

Todo lo que llega al navegador es público. Cualquiera puede abrir las herramientas de desarrollo, buscar en el JavaScript cargado y copiar la clave. Algunas claves están diseñadas para ser públicas, como la anon key de Supabase, y solo son seguras si tus reglas de datos son sólidas. Otras no: claves secretas de pago, claves service-role, claves de proveedores de correo y claves de proveedores de IA que cobran por solicitud.

Qué revisar

• Busca en tu repositorio y en el JavaScript desplegado cadenas que parezcan claves.
• Revisa cualquier variable con prefijo público; esas se envían al cliente por diseño.
• Mira tu historial de Git, porque una clave eliminada hoy puede seguir en un commit antiguo.
• Rota cualquier secreto que haya estado expuesto alguna vez. Borrarlo del código no basta.

La solución es mover las llamadas que necesitan secretos a una función de servidor o a un backend, y que el navegador llame a eso en su lugar.

¿Qué incidentes públicos han afectado a los constructores de apps con IA?

En julio de 2025, investigadores de Wiz descubrieron que Base44, el constructor de apps con IA de Wix, permitía a un atacante registrarse en apps que debían ser privadas usando solo el ID de la app. Se corrigió en menos de un día. La lección no es que una herramienta sea especialmente mala; es que la propia capa de autenticación del constructor forma parte de la seguridad de tu app, y que las apps privadas dependen de ella.

El patrón de Lovable y Supabase es distinto. Es menos un incidente puntual y más una debilidad de configuración recurrente en apps generadas, donde las reglas de RLS faltan o son demasiado permisivas. Me limito a lo que se ha documentado públicamente y no sacaría conclusiones más amplias.

Ambos casos muestran lo mismo: una app construida con prompts puede verse terminada mientras la capa de acceso que hay debajo está abierta.

¿De qué es responsable el constructor y de qué eres responsable tú?

La seguridad es una responsabilidad compartida. El constructor protege su infraestructura y sus cuentas. Tú, como dueño de la app, eres responsable de quién puede leer qué datos y de los datos de tus usuarios.

A veces quedarse en el constructor es la mejor decisión, sobre todo para una herramienta interna o una validación temprana con pocos datos sensibles. Si realmente lo superas, el código hecho en Lovable se puede llevar a GitHub y a tu propio hosting. Sin embargo, mudarse no corrige nada por sí solo; las mismas reglas y claves se van contigo.

¿Puedo pedirle a la IA que corrija sus propios bugs de seguridad?

En parte. Es útil para problemas claros y localizados: agregar validación de entradas, restringir una política que describes con precisión o mover una llamada a una función de servidor. Pero las reglas de datos, las claves y los flujos de pago son justo lo que las herramientas suelen hacer mal, y el mismo punto ciego que creó el bug a menudo lo oculta en la revisión.

Destacan dos problemas. Primero, la IA a menudo dice que una corrección está hecha sin demostrarlo. Segundo, no puede conocer tus reglas de negocio, como quién debe ver una factura o qué pasa cuando un webhook de pago llega dos veces o fuera de orden. Los escáneres de seguridad genéricos tampoco detectan esto, porque los pedidos duplicados y los webhooks de Stripe sin verificar son lógica de negocio, no patrones de vulnerabilidad conocidos.

Mi enfoque: probar con la revisión de dos cuentas de arriba, pedir que una persona lea las políticas y el código de pagos, y corregir los problemas de mayor riesgo en el código existente antes siquiera de considerar una reescritura. Usa la IA como asistente para las ediciones, no como juez de si funcionaron.

¿Quieres una segunda opinión sobre tu app?

Si construiste algo con una herramienta de IA y quieres comparar notas, escríbeme a me@filipeeduardo.dev con el enlace y te diré qué revisaría primero. Esta es una orientación general, no una garantía de seguridad.