Seguridad en vibe coding: 20 cosas que revisar antes de lanzar tu app
La IA escribe código rápido, pero no siempre cierra las puertas. Aquí tienes 20 comprobaciones de seguridad para apps hechas con Lovable, Bolt, Cursor, Claude Code o cualquier herramienta de IA, cada una con una prueba rápida y un prompt para tu IA. Basado en incidentes reales de 2025 y 2026.
··17 min de lectura
Las herramientas de IA escriben código rápido. Yo construyo con un agente de programación con IA cada día, y no volvería atrás. Pero después de muchos años creando software, he aprendido algo sobre la velocidad: el código que funciona no siempre es el código seguro.
Una app puede verse perfecta, pasar todas las pruebas de clics y aun así dejar que cualquier desconocido lea los datos de tus usuarios. No es teoría. Les pasó a muchas apps hechas con vibe coding en 2025 y 2026.
Así que, antes de lanzar, dedica una tarde a este checklist. Cada punto tiene por qué importa, cómo comprobarlo en pocos minutos y un prompt que puedes darle a tu herramienta de IA para arreglarlo. No necesitas ser experto en seguridad para usarlo.
Este checklist cubre los problemas más comunes, no todos. Si tu app maneja pagos, datos de salud o datos de menores, paga también una revisión de seguridad profesional.
En resumen
El código generado por IA a menudo tiene fallos de seguridad. En el estudio de Veracode de 2025, el código escrito por más de 100 modelos de IA tenía fallos de seguridad en el 45% de las tareas.
El problema real más común es sencillo: una base de datos que cualquiera puede leer, porque nunca se activaron las reglas de acceso.
El segundo más común son las claves secretas en el navegador, donde cualquiera puede copiarlas.
La mayoría de las 20 comprobaciones llevan entre 2 y 10 minutos. La lista completa cabe en una tarde.
Al final hay una versión de una página para imprimir.
¿Qué es el vibe coding y por qué importa la seguridad?
El vibe coding es crear software pidiéndole a una IA lo que quieres en lenguaje normal, en lugar de escribir tú el código. Es rápido y funciona. El riesgo es que, cuando no lees el código, tampoco ves lo que falta: una regla de acceso, una comprobación de permisos, un límite. La IA escribe lo que le pides, y casi nadie le pide seguridad.
Lo que les salió mal a otros: incidentes reales
No están aquí para asustarte. Están aquí porque cada uno enseña un punto de la lista.
170 apps de Lovable con bases de datos abiertas (2025). El investigador Matt Palmer analizó 1.645 apps hechas con Lovable y encontró que 170 de ellas (cerca del 10%) tenían endpoints de base de datos a los que podían acceder desconocidos, porque Row Level Security no estaba bien configurado. Se convirtió en el CVE-2025-48757. Lovable rechaza ese CVE y dice que cada cliente es responsable de los datos de su app. En cualquier caso, la lección es la misma: compruébalo tú.
Más de 2.000 vulnerabilidades en 5.600 apps (octubre de 2025). La empresa de seguridad Escape analizó más de 5.600 apps públicas hechas con vibe coding y encontró más de 2.000 vulnerabilidades, más de 400 secretos expuestos y 175 casos de datos personales expuestos, incluidos historiales médicos y números de cuenta bancaria. Y dicen que esas cifras son un mínimo.
Moltbook: 1,5 millones de claves de API (febrero de 2026). Investigadores de Wiz descubrieron que Moltbook, una red social para agentes de IA hecha con vibe coding, tenía una clave de Supabase en su JavaScript del navegador y nada de Row Level Security. Cualquiera podía leer y escribir toda la base de datos de producción: 1,5 millones de tokens de API, 35.000 correos y mensajes privados. Según Wiz, todo se reducía a "un único ajuste de configuración de Supabase".
Base44: saltarse el inicio de sesión (julio de 2025). Wiz encontró un fallo en Base44, un constructor de apps con IA: con solo el ID público de una app, un atacante podía crear una cuenta verificada en apps privadas y saltarse su inicio de sesión, incluido el inicio de sesión único (SSO). Wix, dueña de Base44, lo arregló en menos de 24 horas.
Un agente de IA borró una base de datos de producción (julio de 2025). Durante una prueba de Jason Lemkin, fundador de SaaStr, el agente de IA de Replit ejecutó comandos destructivos sobre una base de datos real, aunque se le había dicho que no hiciera cambios sin aprobación. Después, Replit empezó a separar automáticamente las bases de datos de desarrollo y de producción.
Regla general: si el navegador puede verla, da por hecho que todo el mundo puede verla.
El checklist
Claves y secretos
1. Ninguna clave secreta en el navegador
Por qué: todo lo que tu front-end envía al navegador lo puede leer cualquiera. Abres las herramientas de desarrollo y ahí está. Escape encontró más de 400 secretos así.
Compruébalo: compila tu app y busca en los archivos JavaScript generados patrones de claves: sk_live, sk-proj, sk-ant, service_role, sb_secret, secret. En un sitio en línea, abre las herramientas de desarrollo, ve a Sources y busca con Ctrl+Shift+F (Cmd+Option+F en Mac).
Pídele a tu IA: "Haz una lista de cada clave de API y secreto que usa esta app. Para cada uno, dime si llega al navegador. Mueve cada clave secreta a código del servidor (una ruta de API, una edge function o un backend) y llámala desde ahí".
2. Saca los secretos de tu código y de tu historial de git
Por qué: las claves escritas directamente en el código terminan en git. Aunque las borres después, se quedan en el historial.
Compruébalo: asegúrate de que los archivos .env están en .gitignore. Busca claves en tu repositorio. Si un secreto se subió alguna vez, cámbialo (crea una clave nueva y borra la vieja). Borrar la línea no basta.
Pídele a tu IA: "Encuentra claves, contraseñas o tokens escritos directamente en este proyecto y muévelos a variables de entorno. Dime qué añadir a .gitignore".
3. Sabe qué claves están pensadas para ser públicas
Por qué: algunas claves están diseñadas para ser públicas. La clave anon de Supabase (ahora llamada publishable) es una de ellas. Pero solo es segura si Row Level Security protege tus tablas (punto 5). La clave service role (ahora la clave secreta) se salta todas esas reglas y nunca debe salir de tu servidor.
Compruébalo: para cada clave de tu front-end, busca la documentación del proveedor y confirma que está pensada para ser pública.
Pídele a tu IA: "Para cada clave usada en el front-end, explica si el proveedor la diseñó para ser pública y qué protege mis datos si alguien la copia".
4. Pon límites de gasto a las APIs de pago
Por qué: si se filtra una clave de una API de IA o de pago, otra persona puede disparar tu factura.
Compruébalo: en los paneles de OpenAI, Anthropic, Google u otros, pon un presupuesto mensual y alertas. Usa una clave distinta por app, para poder desactivar una sin romper las demás.
Pídele a tu IA: "Añade un límite de uso por usuario a cada endpoint que llame a una API de pago, y dime dónde poner un presupuesto mensual en cada proveedor".
Base de datos y acceso a los datos
5. Activa Row Level Security en todas las tablas
Por qué: es el problema número uno de los incidentes de arriba. Sin reglas de acceso, la clave pública del punto 3 puede leer y escribir toda la base de datos.
Compruébalo: en Supabase, abre el Table Editor y busca tablas marcadas con RLS desactivado. Actívalo en todas y luego escribe políticas: quién puede leer, insertar, actualizar y borrar cada fila. Otras bases de datos tienen sus propias reglas de acceso. La idea es la misma.
Pídele a tu IA: "Activa Row Level Security en todas las tablas. Para cada tabla, escribe políticas para que los usuarios solo puedan leer y cambiar sus propias filas, y explica cada política en una frase".
6. Prueba tu app como un desconocido
Por qué: tú siempre pruebas como tú, el dueño. Los atacantes no.
Compruébalo: crea una segunda cuenta. Entra con ella e intenta abrir las páginas de la primera cuenta cambiando los ID en la barra de direcciones (/facturas/123 por /facturas/124). Luego cierra sesión y vuelve a intentarlo. Prueba también a llamar a tu API directamente con la sesión de la segunda cuenta. Si ves algo que no es tuyo, tienes un problema (se llama IDOR).
Pídele a tu IA: "Escribe una prueba que cree dos usuarios y compruebe que el usuario B recibe un 403 o un 404 en cada lectura y escritura sobre los datos del usuario A, en todas las rutas".
7. Comprueba los permisos en el servidor, no en la interfaz
Por qué: ocultar un botón no es seguridad. Cualquiera puede enviar la petición que enviaría el botón.
Compruébalo: para cada acción que cambia datos (crear, editar, borrar, pagar, invitar), busca el código del servidor y confirma que comprueba quién lo pide y si tiene permiso.
Pídele a tu IA: "Haz una lista de cada ruta o función del servidor que cambia datos. Para cada una, enséñame la línea que comprueba el permiso del usuario. Añade la comprobación donde falte".
8. Mantén a tu agente de IA lejos de los datos de producción
Por qué: un agente que puede llegar a tu base de datos real también puede borrarla, como mostró el caso de Replit. Los agentes se equivocan cuando se confunden, y son rápidos.
Compruébalo: usa una base de datos de desarrollo separada, con datos falsos. No le des al agente las contraseñas de producción. Si de verdad necesita leer producción, dale una cuenta de solo lectura. Y ten copias de seguridad (punto 20) antes de dejar que cualquier herramienta ejecute comandos.
Pídele a tu IA: "Configura una base de datos de desarrollo separada con datos de ejemplo, y asegúrate de que ningún comando ni script de este proyecto pueda llegar a producción sin un paso manual".
Inicio de sesión y sesiones
9. Usa un sistema de inicio de sesión probado
Por qué: el inicio de sesión está lleno de detalles difíciles: el hash de contraseñas, los tokens de recuperación, la verificación del correo, la caducidad de las sesiones. La IA puede escribir algo que parece correcto pero olvida uno de ellos. El fallo de Base44 estaba en la lógica de inicio de sesión.
Compruébalo: usa la autenticación de tu plataforma (Supabase Auth, Firebase Auth) o una librería o servicio conocido. No le pidas a la IA que invente la suya.
Pídele a tu IA: "¿Usamos una librería de autenticación probada para el registro, el inicio de sesión, la recuperación de contraseña y la verificación del correo? Si algo es código propio, sustitúyelo por las funciones de la librería".
10. No guardes los tokens de sesión en localStorage
Por qué: cualquier script de tu página puede leer lo que hay en localStorage. Con un solo fallo XSS (punto 14), el atacante tiene las sesiones de tus usuarios.
Compruébalo: abre las herramientas de desarrollo, ve a Application y mira Local Storage. Si ves un token, plantéate moverlo a una cookie HttpOnly, Secure y SameSite, que los scripts no pueden leer. Así lo hace Axiean: los scripts de la página nunca ven el token de sesión.
Pídele a tu IA: "¿Dónde se guardan los tokens de sesión? Si están en localStorage, muévelos a cookies HttpOnly, Secure y SameSite, y añade protección CSRF a las peticiones que cambian datos".
11. Limita los intentos de inicio de sesión y los correos
Por qué: sin límites, alguien puede probar miles de contraseñas, o usar tu formulario de "olvidé mi contraseña" para enviar miles de correos.
Compruébalo: pon mal la contraseña 20 veces. Pide un correo de recuperación 10 veces. Si nada te detiene, añade límites. En Axiean, una cuenta permite 10 intentos de contraseña cada 15 minutos, y cada dirección recibe como máximo 3 correos de un mismo tipo por hora.
Pídele a tu IA: "Añade límites de uso al inicio de sesión, al registro, a la recuperación de contraseña y a cualquier endpoint que envíe correos: por dirección IP y por cuenta o dirección de correo".
12. No reveles quién tiene cuenta
Por qué: si tu formulario de registro dice "este correo ya está registrado", cualquiera puede comprobar si una persona usa tu app. En algunas apps (salud, citas) eso ya es un dato privado.
Compruébalo: regístrate con un correo que ya tiene cuenta. La respuesta debe ser igual que con un correo nuevo ("revisa tu bandeja de entrada"). Axiean, en su lugar, le envía al dueño real un correo de "ya tienes una cuenta".
Pídele a tu IA: "Haz que el registro y la recuperación de contraseña respondan igual tenga o no cuenta ese correo".
Datos de entrada, salida y archivos
13. Valida cada dato de entrada en el servidor
Por qué: las comprobaciones del formulario en el navegador son para comodidad. Los atacantes se las saltan y envían lo que quieren.
Compruébalo: cada ruta del servidor debe comprobar tipos, longitudes y valores permitidos antes de usar los datos. Una librería de esquemas (como zod) hace que esto sea corto y fácil de leer.
Pídele a tu IA: "Añade validación en el servidor con un esquema en cada ruta que recibe datos. Rechaza campos desconocidos y limita la longitud de los textos".
14. Nunca muestres el texto de los usuarios como HTML sin filtrar
Por qué: si los usuarios pueden hacer que tu página ejecute su HTML, pueden ejecutar scripts en los navegadores de otros usuarios (XSS). Veracode encontró que los modelos de IA no se defendieron del XSS en el 86% de las tareas relevantes.
Compruébalo: busca en tu código dangerouslySetInnerHTML, innerHTML y v-html. Cada uso con contenido de usuarios necesita limpieza o, mejor, desaparecer.
Pídele a tu IA: "Encuentra cada lugar donde el contenido de los usuarios se muestra como HTML. Sustitúyelo por texto seguro, o límpialo con una librería conocida".
15. Revisa cada archivo subido
Por qué: una "imagen" puede ser otra cosa. Y una foto normal del móvil a menudo lleva la ubicación GPS de donde se tomó.
Compruébalo: limita en el servidor los tipos y tamaños de archivo. Comprueba qué es realmente el archivo, no solo su nombre. Vuelve a codificar las imágenes, lo que también elimina los metadatos ocultos. Axiean recodifica cada imagen subida justo por esto.
Pídele a tu IA: "En el servidor, comprueba los archivos subidos por su contenido (no por la extensión), limita su tamaño, recodifica las imágenes y elimina metadatos como la ubicación GPS".
Pagos
16. Verifica los webhooks y no te fíes nunca de los precios del navegador
Por qué: si tu servidor cree al navegador sobre los precios, alguien puede pagar 1 € por un plan de 100 €. Si cree cualquier petición de "pago completado", alguien puede inventarse una.
Compruébalo: los precios deben salir de tu servidor o de tu proveedor de pagos, nunca de la petición. Verifica la firma de cada webhook (Stripe y otros te dan un secreto para eso).
Pídele a tu IA: "Asegúrate de que los precios se leen en el servidor desde nuestra lista de productos, y verifica la firma de cada webhook de pago antes de actuar".
Dependencias y funciones de IA
17. Revisa cada paquete que añade tu IA
Por qué: la IA a veces sugiere paquetes que no existen. Un estudio presentado en USENIX Security 2025 encontró que el 21,7% de las muestras de código de modelos abiertos, y el 5,2% de los modelos comerciales, mencionaban paquetes inexistentes. Los atacantes pueden publicar malware con esos nombres. Se llama slopsquatting.
Compruébalo: antes de instalar un paquete nuevo, búscalo en npm o PyPI. ¿Es el auténtico, con descargas e historial reales? Guarda tu archivo de bloqueo (lock file) en git y ejecuta npm audit (o el equivalente de tu lenguaje).
Pídele a tu IA: "Haz una lista de cada dependencia que añadiste. Para cada una, dame el enlace a su página y explícame por qué la necesitamos. Quita las que no hagan falta de verdad".
18. Si tu app usa un LLM, no te fíes de lo que responde
Por qué: si los usuarios pueden hablar con una IA dentro de tu app, pueden intentar que ignore tus instrucciones (prompt injection). Si esa IA también puede usar herramientas (enviar correos, borrar datos, gastar dinero), pueden intentar usarlas.
Compruébalo: dale al modelo solo las herramientas que necesita. Pide confirmación al usuario antes de cualquier cosa que cambie datos o cueste dinero. Nunca pongas secretos en el prompt del sistema.
Pídele a tu IA: "Haz una lista de cada acción que puede activar el modelo de IA de esta app. Añade un paso de confirmación del usuario para todo lo que cambie datos, envíe mensajes o cueste dinero".
El día del lanzamiento y después
19. Activa HTTPS y las cabeceras de seguridad, y cierra CORS
Por qué: las cabeceras les dicen a los navegadores que bloqueen ataques comunes, como cargar tu sitio dentro de la página de otro. Un CORS con * en una API que usa cookies o tokens puede dejar que otros sitios la usen.
Compruébalo: pasa tu sitio por un analizador de cabeceras gratuito, como securityheaders.com o el HTTP Observatory de Mozilla. Asegúrate de que tu API solo acepta peticiones desde la dirección de tu propio sitio.
Pídele a tu IA: "Añade cabeceras de seguridad (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, frame-ancestors) y limita CORS a nuestro propio dominio".
20. Ten copias de seguridad, registros seguros y una forma de avisar de problemas
Por qué: algún día algo saldrá mal. Lo que importa es si puedes recuperarte y si te enteras pronto.
Compruébalo: activa copias de seguridad diarias automáticas y restaura una al menos una vez para asegurarte de que funcionan. Comprueba que tus registros no guardan contraseñas, tokens ni números de tarjeta completos. Añade una forma visible de que la gente te avise de problemas. (En Axiean es Informar de un problema).
Pídele a tu IA: "Comprueba que nuestros registros nunca incluyen contraseñas, tokens ni datos personales, configura copias de seguridad diarias de la base de datos y escribe los pasos para restaurar una".
El checklist en una página
Guárdalo, imprímelo o tenlo junto a tu editor.
El checklist completo en una página.
Cómo lo hago en Axiean
Uso un agente de programación con IA para Axiean, así que aplico esta lista a mi propio trabajo. Algunas cosas que decidí pronto:
El navegador nunca habla directamente con la API. Habla con el servidor web, que pasa las peticiones. La API rechaza a cualquier otro.
Los tokens de sesión viven en cookies HttpOnly, así que ningún script de la página puede leerlos, y cada petición que cambia datos se comprueba para asegurar que viene del propio Axiean.
Límites en todas partes: por cuenta para las contraseñas, por dirección para los correos, por visitante para todo lo demás.
Las imágenes subidas se recodifican, así que una foto de perfil nunca lleva su ubicación GPS.
El desarrollo tiene su propia base de datos, separada de producción.
Nada de esto necesitó conocimientos especiales. Necesitó que alguien lo pidiera. La IA escribió la mayor parte del código, pero las preguntas de esta lista salieron de mí. Ese es el trabajo de verdad ahora: saber qué preguntar.
Después del checklist: a lanzar
Cuando tu app pase estas comprobaciones, estás listo para enseñarla a desconocidos. Mi guía sobre dónde lanzar tu producto compara nueve sitios, y cómo conseguir tus primeros usuarios explica cómo convertir un lanzamiento en usuarios reales.
Si lo creaste con IA, también puedes publicarlo en Axiean, donde los makers dicen qué herramientas de IA usaron.
Preguntas frecuentes
¿Es seguro el vibe coding?
Puede serlo. El código que escribe la IA no es más peligroso porque lo haya escrito una máquina. Es peligroso cuando nadie lo revisa. Los incidentes de arriba ocurrieron porque faltaban ajustes básicos (como Row Level Security), no porque la IA sea especialmente mala. Usa este checklist y prueba como un desconocido.
¿Qué es Row Level Security (RLS) en Supabase?
Es una función de PostgreSQL que Supabase usa para decidir qué filas puede ver o cambiar cada usuario. Con RLS activado y buenas políticas, la clave pública solo da acceso a lo que cada usuario puede ver. Con RLS desactivado, esa clave da acceso a toda la tabla.
¿Es seguro usar Lovable?
Lovable es una herramienta, y como cualquier herramienta depende de cómo la uses. El CVE de 2025 trataba de apps sin Row Level Security. Si usas Lovable con Supabase, activa RLS en todas las tablas, escribe políticas y prueba con una segunda cuenta (puntos 5 y 6).
¿Es seguro exponer la clave anon de Supabase?
Sí, está diseñada para ser pública, pero solo si Row Level Security está activado y tus políticas son correctas. Sin RLS, esa clave da acceso total a tus datos, como mostró el caso de Moltbook. La clave service role (secreta) nunca debe ser pública.
¿Puede la IA revisar la seguridad de mi app?
En parte. Los prompts de este checklist ayudan mucho, y la IA es buena encontrando comprobaciones que faltan cuando le haces la pregunta correcta. Pero pruébala también tú como un desconocido (punto 6), y pide una revisión profesional si manejas datos sensibles.
¿Qué es el slopsquatting?
Es cuando los atacantes publican malware con nombres de paquetes que las herramientas de IA se inventan. Si tu IA sugiere un paquete que no existe y alguien registró ese nombre, al instalarlo ejecutas su código. Revisa siempre los paquetes nuevos antes de instalarlos (punto 17).
La gente ya pregunta a la IA qué producto usar. Si no puede leer tu sitio, no apareces en la respuesta. Una guía práctica de optimización para motores generativos (GEO) para makers, con los nombres exactos de los rastreadores, una prueba de 2 minutos y lo que configuramos en Axiean.
Product Hunt, Hacker News, Reddit, BetaList, Uneed, Peerlist y más, comparados con sus reglas y precios reales a octubre de 2026. Cuál encaja con tu producto, cuánto cuesta cada uno y cómo combinarlos en un solo plan de lanzamiento.
··12 min de lectura
La IA hizo que crear una app sea rápido y barato, así que todo el mundo está lanzando. Ahora lo difícil es que te encuentren. Aquí tienes los números reales del cambio y el método de cinco pasos que uso para conseguir los primeros usuarios de un producto creado con IA.
Vahid Aslani
