El vibe coding no es seguro por defecto, pero tampoco es inseguro por naturaleza: una app web generada con IA es tan segura como las comprobaciones que alguien le haya hecho. En las apps creadas con creadores de IA aparecen una y otra vez los mismos fallos: datos que cualquiera puede leer, claves secretas en el navegador, reglas que solo se aplican en la interfaz. Una persona sin perfil técnico puede probar cada uno en unos minutos, y cada uno tiene un prompt de seguimiento que lo corrige.
Esta lista es para fundadores, autónomos y equipos pequeños que están a punto de dar acceso a un primer usuario real a una app creada con un creador de IA. Si el método es nuevo para usted, empiece por nuestra guía de vibe coding. Si su app usa Supabase, los detalles de la parte de base de datos están en nuestra guía de seguridad a nivel de fila en Supabase.
Por qué las apps creadas con IA fallan de la misma manera
Un creador de IA optimiza para que la app funcione en pantalla, y una pantalla que funciona no dice nada sobre quién más puede llegar a los datos que hay detrás. Cuando usted pide "un panel donde cada cliente vea sus facturas", el modelo construye primero la pantalla. Que la base de datos se niegue a devolver las facturas de otros clientes es un trabajo aparte, y solo se hace si el prompt o los valores por defecto del creador lo piden.
Un ejemplo público muestra la forma del problema. En 2025 se publicó un registro de vulnerabilidad (CVE-2025-48757) que describe políticas de seguridad a nivel de fila insuficientes en sitios generados con Lovable, hasta el 2025-04-15, que permitían a visitantes no autenticados leer o escribir en tablas. La entrada de la National Vulnerability Database señala también que el proveedor discute el hallazgo y afirma que cada cliente es responsable de proteger los datos de su propia aplicación. Ambas afirmaciones llevan a la misma conclusión práctica: quien publica la app debe verificar sus reglas de acceso, sea cual sea la herramienta que la escribió.
Los siete fallos de un vistazo
La mayoría de estos fallos se corresponden con el OWASP Top 10, la lista de referencia de riesgos de las aplicaciones web, en su edición de 2025. La correspondencia de abajo usa los nombres de categoría de esa lista.
| Fallo | Qué hace un atacante | Categoría OWASP 2025 | Su prueba de 10 minutos |
|---|---|---|---|
| 1. Falta de seguridad a nivel de fila | Lee o edita cualquier tabla a través de la API pública | A01 Broken Access Control | Dos cuentas, comparar lo que ve cada una |
| 2. Claves secretas en el frontend | Copia la clave del navegador y gasta su dinero | A02 Security Misconfiguration | Pestaña de red y código fuente de la página |
| 3. Reglas solo en la interfaz | Llama directamente a la API y se salta el botón oculto | A01 Broken Access Control | Repetir una petición con el rol equivocado |
| 4. Páginas de administración accesibles por URL | Escribe /admin en la barra de direcciones | A01 Broken Access Control | Abrir las URL de administración sin sesión y como usuario normal |
| 5. Subida de archivos sin validar | Sube archivos enormes, incorrectos o públicos | A06 Insecure Design | Subir un archivo incorrecto y abrir su enlace sin sesión |
| 6. Dependencias desactualizadas | Aprovecha un fallo conocido de un paquete antiguo | A03 Software Supply Chain Failures | Ejecutar el comando de auditoría de paquetes |
| 7. Sin límites de uso | Inunda el registro o agota sus créditos de IA | A06 Insecure Design | Repetir una petición 50 veces y ver qué pasa |
1. Falta de seguridad a nivel de fila
Con un backend en Supabase, el navegador habla con la base de datos a través de una API pública, así que lo único que se interpone entre un visitante y sus tablas es la seguridad a nivel de fila (RLS, row level security): reglas asociadas a cada tabla que dicen qué filas puede leer o escribir un usuario. Una tabla sin RLS activada puede ser leída por cualquiera que tenga la clave pública, y esa clave está en el navegador por diseño. Supabase explica el mecanismo en su documentación sobre seguridad a nivel de fila.
La prueba lleva cinco minutos. Cree dos cuentas, A y B, con correos distintos. Como A, cree un registro (una factura, una nota, un proyecto). Cierre sesión, inicie sesión como B y busque el registro de A en todas las listas y búsquedas. Después abra las herramientas de desarrollo del navegador, vaya a la pestaña Network (Red), recargue la página, haga clic en una petición a la base de datos y lea la respuesta: solo debe contener las filas de B. Por último, cierre sesión y recargue la misma página: las peticiones no deben devolver nada o deben devolver un error.
Prompt de seguimiento: "Enumera todas las tablas de la base de datos indicando si la seguridad a nivel de fila está activada y qué políticas se aplican. Activa RLS en cada tabla que no la tenga y escribe políticas para que un usuario solo pueda seleccionar, insertar, actualizar y eliminar filas donde user_id sea igual a su propio id. Muéstrame las políticas y explica cualquier tabla que hayas dejado pública a propósito."
2. Claves secretas en el frontend
Todo lo que se envía al navegador es público, incluida cualquier clave que pueda encontrarse en el código fuente de la página. Algunas claves están pensadas para ser públicas (la clave pública de Supabase, protegida por RLS). Otras no: las claves secretas de pago, las claves de proveedores de IA, las claves de servicios de correo, la clave service role de la base de datos. Un visitante que copie una de ellas puede enviar correos en su nombre o ejecutar peticiones de IA a su cargo.
Para probarlo, abra la app publicada, abra las herramientas de desarrollo, vaya a la pestaña Network y a la pestaña Sources, y busque los primeros caracteres de cada secreto que use (por ejemplo "sk_" para una clave de pago) y el nombre de cualquier proveedor. Busque también en el código del proyecto y en su repositorio de GitHub si lo exporta. Un secreto en un repositorio público se considera filtrado aunque después lo borre.
Prompt de seguimiento: "Busca en todo el proyecto claves de API, tokens y secretos en el código del cliente. Mueve cada llamada que necesite un secreto a una función edge del lado del servidor, lee la clave de las variables de entorno y no uses nunca la clave service role en el navegador. Enumera lo que has movido." Si un secreto quedó expuesto, rótelo en el proveedor: borrar el código no cancela la clave.
3. Autorización comprobada solo en la interfaz
Ocultar un botón es una decisión de diseño, no un permiso. Si el botón de eliminar está oculto para el rol "lector" pero la base de datos acepta de todos modos la petición de eliminar, cualquier lector con las herramientas de desarrollo puede enviarla. Las reglas deben aplicarse donde viven los datos, y la interfaz solo debe reflejarlas.
Para probarlo, inicie sesión con el rol más bajo, realice una acción permitida como leer y, en la pestaña Network, copie esa petición (clic derecho, "Copy as fetch"). Edítela para convertirla en algo prohibido, como cambiar el id de otro registro o un campo de rol, y ejecútela en la consola. Si funciona, la regla solo existe en la interfaz. Compruebe también que un usuario no pueda editar su propio campo de rol o de plan.
Prompt de seguimiento: "Para cada rol, enumera las acciones que puede realizar en cada tabla. Aplícalas con políticas de base de datos, no solo en la interfaz. Impide que los usuarios actualicen sus propias columnas role, plan o user_id."
4. Páginas de administración accesibles por URL
Una página de administración que simplemente no aparece en el menú sigue siendo accesible para cualquiera que adivine la dirección. La página debe comprobar el rol antes de mostrar nada, y los datos que hay detrás deben estar protegidos por las políticas del punto 1.
Para probarlo, enumere sus rutas de administración (/admin, /settings/users, /dashboard/all). Abra cada una en una ventana privada sin sesión y después con sesión de usuario normal. Debería llegar a una página de inicio de sesión o de "acceso denegado", y la pestaña Network no debería mostrar datos de administración en ninguna respuesta.
Prompt de seguimiento: "Protege todas las rutas de administración para que solo los usuarios con el rol de administrador puedan abrirlas, redirige a todos los demás y asegúrate de que las consultas de datos de esas páginas también fallen para quienes no son administradores."
5. Subida de archivos sin validación
Un campo de subida que acepta cualquier archivo, de cualquier tamaño, en una carpeta pública permite que desconocidos alojen contenido en su dominio y llenen su almacenamiento. Los documentos privados (contratos, currículums, facturas) no deben poder leerse a través de un enlace fácil de adivinar.
Para probarlo, suba un archivo de tipo incorrecto (un ejecutable renombrado como .jpg) y un archivo muy grande. Después copie el enlace de un documento privado subido y ábralo en una ventana privada. Si se abre, el bucket es público.
Prompt de seguimiento: "Restringe las subidas a estos tipos de archivo: [lista] y a un tamaño máximo de [x MB], comprobado al subir. Haz el bucket privado, añade políticas de almacenamiento para que un usuario solo pueda leer sus propios archivos y sirve los archivos mediante enlaces firmados que caduquen."
6. Dependencias desactualizadas
Una app se compone de cientos de paquetes de código abierto, y un paquete con un fallo conocido es una puerta de entrada ya preparada. OWASP lo agrupa bajo los fallos de la cadena de suministro de software. Además, la IA puede elegir una versión antigua de un paquete que aprendió de ejemplos más viejos.
La prueba es un solo comando en el proyecto exportado: "npm audit" enumera las vulnerabilidades conocidas de los paquetes instalados. Si no puede ejecutarlo, pida a la IA que haga la revisión equivalente. Vuelva a programarla antes de cada versión importante.
Prompt de seguimiento: "Comprueba si las dependencias tienen vulnerabilidades conocidas o versiones mayores desactualizadas. Actualiza las que tengan corrección, evita los cambios que rompan la compatibilidad y enumera lo que no hayas podido actualizar y por qué. Elimina los paquetes que la app no use."
7. Sin límites de uso en el registro ni en los endpoints de IA
Sin límites, un script puede crear miles de cuentas falsas o llamar a su endpoint de IA hasta que crezca la factura de su proveedor, no el número de sus usuarios. Dos lugares importan más: el registro (y el restablecimiento de contraseña, que envía correos) y cualquier función que llame a una API de pago.
Para probarlo, envíe la misma petición de registro o de IA muchas veces seguidas desde las herramientas de desarrollo o con un script sencillo y observe si algo la ralentiza o la bloquea. Compruebe también que los endpoints de IA exigen un usuario con sesión iniciada y que un usuario no puede enviar un prompt de 10 MB.
Prompt de seguimiento: "Exige inicio de sesión en cada función edge que llame a una API de pago, limita a cada usuario a [n] llamadas por hora, limita el tamaño de la entrada y devuelve un error claro cuando se alcance el límite. Activa la confirmación por correo y un captcha en el registro."
Datos personales y RGPD
Si sus usuarios están en Europa, la app contiene datos personales y usted es responsable de ellos, sea cual sea la herramienta que construyó la app. Los fallos de seguridad anteriores son también la vía habitual por la que se filtran datos personales. Además, revise lo básico: una política de privacidad que coincida con lo que la app recoge realmente, una forma de eliminar la cuenta y los datos de un usuario, y que no haya datos personales en los registros o en las analíticas que usted no tuviera intención de enviar. Nuestra guía sobre el RGPD y las apps no-code con IA trata el aspecto legal con más detalle.
Prompt de seguimiento: "Añade una función de eliminación de cuenta que borre las filas y los archivos del usuario, enumera cada campo de datos personales que guardamos y por qué, y asegúrate de que no se escriban datos personales en los registros."
Qué hace Cadrant por defecto y qué no
Cadrant, nuestro creador, genera apps de React con un backend en Supabase en su propia cuenta de Supabase. Por defecto, la IA escribe las migraciones de la base de datos con políticas de seguridad a nivel de fila en las tablas por usuario, incluidas las políticas de almacenamiento, y puede inspeccionar el esquema y las políticas actuales antes de modificarlos. Las claves secretas no se colocan en el código del cliente: las integraciones como Stripe, OpenAI o los proveedores de correo se ejecutan mediante funciones edge de Supabase, con los secretos guardados como variables de entorno. Nuestra documentación lo describe en las páginas de funciones edge y de variables de entorno.
Los valores por defecto reducen el número de errores; no sustituyen la prueba. Un prompt todavía puede pedir una tabla pública, un modelo todavía puede olvidar una política en una tabla que usted añada más tarde, y ningún creador revisa sus reglas de negocio por usted. Haga la prueba de las dos cuentas después de cada cambio grande, sea cual sea la herramienta que use.
Lista de comprobación antes del lanzamiento
Cuando la app maneja pagos, datos de salud u otra información regulada, una revisión puntual por parte de un profesional de la seguridad compensa su coste: esta lista detecta los fallos habituales, no todos los fallos. Para la parte de construcción, consulte nuestra página del creador de apps con IA.