Respuesta breve
Una app creada con prompts está pensada para funcionar en pantalla, no para resistir a un desconocido. Los fallos habituales son la falta de comprobación de propiedad, las claves en el código o en su historial y las tablas sin reglas por fila. Una prueba de un día, hecha como si fueras un extraño, encuentra lo evidente. Si cada arreglo rompe otra cosa, reconstruir puede salir más barato.
Por qué una demo que funciona aún no es una app segura
La seguridad del vibe coding empieza con una observación sencilla. Describes una app a Cursor, Lovable, Bolt o v0, la herramienta escribe el código y en pantalla todo funciona. En ese ciclo nadie pregunta si un desconocido podría abrir la misma dirección y leer los registros de otra persona. La demo pasa porque quien la prueba es una sola persona, y además la dueña de cada fila.
El riesgo crece el día en que llegan usuarios reales. Con ellos llegan nombres, pedidos y pagos. La lista OWASP Top 10:2021 de riesgos de aplicaciones web muestra que esto es ingeniería corriente y no hackeo exótico. Las secciones siguientes recorren los puntos débiles con los que una app creada con IA se topa primero y lo que conviene revisar antes de lanzarla.
Control de acceso roto, la debilidad que OWASP pone primera
En el OWASP Top 10:2021 el control de acceso roto ocupa el primer puesto, tras subir desde el quinto. OWASP resume la idea en una línea: el control de acceso aplica una política para que los usuarios no puedan actuar fuera de los permisos previstos. OWASP anota además que el 94 % de las aplicaciones de sus datos se probaron en busca de alguna forma de este fallo, así que es el caso habitual.
En una app creada con prompts, el hueco puede aparecer en lugares reconocibles. Una página desaparece del menú pero se abre si escribes su dirección, lo que OWASP llama navegación forzada. Una petición lleva el número de una cuenta o un pedido, y al cambiarlo se ve el registro de otro cliente. Un endpoint de guardado o borrado comprueba que la persona inició sesión, pero no que el registro sea suyo. OWASP incluye la falta de controles en POST, PUT y DELETE entre sus ejemplos.
Los remedios de OWASP son sencillos. Denegar por defecto, salvo los recursos públicos. Aplicar las reglas en código de servidor de confianza, porque el navegador no puede vigilarse a sí mismo. Basar el acceso en quién es el propietario de cada registro y anotar los fallos para que alguien note los intentos repetidos. Un botón oculto no es una regla: si la única protección es que el enlace de administración no se muestra, la app no tiene control de acceso.
Claves y secretos que acaban donde todos pueden leerlos
Toda app que habla con un servicio de pagos, de correo o con un modelo de IA necesita una clave secreta. La documentación de Vercel describe las variables de entorno como pares clave-valor configurados fuera de tu código fuente. El fallo es el contrario: una clave pegada en un archivo, subida al repositorio o enviada al navegador junto con la página.
La documentación de GitHub sobre el escaneo de secretos dice que revisa todo el historial de Git, en todas las ramas, en busca de credenciales incrustadas como claves de API, contraseñas y tokens. De ahí se deduce algo que muchos pasan por alto: borrar la clave del archivo de hoy no la elimina del historial. La guía de GitHub sobre secretos filtrados afirma que quitar el secreto del código, hacer un nuevo commit o recrear el repositorio no evita el abuso, y que todo secreto filtrado debe considerarse comprometido.
La solución es revocar la clave con su proveedor y emitir una nueva; GitHub lo llama el paso de remediación más importante. Después revisa los registros del proveedor por si hay usos que no reconoces, y guarda la clave nueva en los ajustes del alojamiento. Vercel añade un detalle práctico: una variable modificada se aplica solo a los despliegues nuevos, así que hay que volver a desplegar tras rotarla.
Reglas de base de datos abiertas y la trampa de Row Level Security
Cuando el navegador se conecta directamente a una base de datos alojada, las reglas de la base pasan a ser el único guardián. La documentación de Supabase sobre Row Level Security lo dice sin rodeos: una tabla en un esquema expuesto sin RLS es legible y modificable por cualquier rol que tenga permisos sobre ella. Activar RLS tampoco basta. La misma página indica que las tablas necesitan además permisos y políticas adecuados, y que con RLS activado la API no devuelve datos con una clave pública hasta que exista una política.
El segundo punto de esa página se refiere a la clave poderosa. Una clave secreta funciona mediante el rol de servicio, que se salta Row Level Security, y la guía advierte contra usarla en navegadores. Luego prueba como un extraño: entra con un usuario e intenta leer las filas de otro. La propia guía recomienda probar cada tabla con casos de permiso y de denegación para cada rol.
Errores de configuración: valores por defecto, páginas de error y restos
OWASP llama a la siguiente familia configuración de seguridad incorrecta y da tres ejemplos cotidianos. Las cuentas por defecto y sus contraseñas siguen activas y sin cambiar. El manejo de errores muestra a los usuarios trazas de pila u otros mensajes demasiado detallados. Hay funciones innecesarias activadas, como páginas, cuentas o privilegios de más. Un proyecto generado puede traer las tres: un administrador de demostración, una ruta de depuración de la primera sesión, un error en bruto impreso en pantalla.
El consejo de prevención de OWASP se lee como una lista de limpieza. Partir de una plataforma mínima, sin funciones, componentes, documentación ni ejemplos innecesarios. Y verificar los ajustes con comprobaciones automáticas, no de memoria.
Una revisión de seguridad del vibe coding en un día, antes del primer cliente
Empieza con cinco pruebas que no requieren herramientas. Cierra sesión y abre las direcciones de las páginas privadas. Entra como usuario normal e intenta las direcciones de administración. Cambia el número en la dirección de un registro y mira si aparece el de otra persona. Crea dos usuarios de prueba e intenta leer, editar y borrar los datos del otro. Por último, provoca un error a propósito y lee lo que imprime la página.
Después mira dónde vive cada cosa. Busca en el repositorio y en los archivos que carga el navegador cualquier cosa que parezca una clave. Confirma que las claves de producción están en los ajustes del alojamiento y no en el código. Comprueba que producción usa su propia base, separada de los datos de prueba, y que puede entrar como administrador alguien más que quien lo construyó.
Esto es una prueba rápida, no una auditoría. OWASP y la documentación de las plataformas citadas son la referencia, y aprobar solo significa que no has encontrado los huecos evidentes, no que no existan. Si la app maneja pagos, datos de salud, datos de menores o datos personales de personas de otros países, se aplican además otras reglas. Consulta tu caso con un abogado.
Reparar o reconstruir: cómo decidir con una lista escrita
Reparar tiene sentido cuando la estructura se lee bien, las páginas corresponden a funciones reales y los problemas hallados están en ajustes y en unos pocos endpoints. Corregir comprobaciones de propiedad, mover claves, añadir políticas de base de datos y ordenar el despliegue es trabajo acotado y con final claro.
Reconstruir es la respuesta honesta cuando cada arreglo rompe otra cosa, cuando nadie sabe decir dónde se guardan los datos o cuando el modelo de datos no encaja con el negocio. Entonces los parches solo añaden peso. No decidas por intuición. Pide a alguien que no escribió la app una lista escrita de problemas ordenada por riesgo y decide con ella delante. Convierte una discusión en una comparación.
Qué preparar antes de encargar el rescate de una app
Quien revisa necesita muy poco para empezar. Prepara acceso al repositorio, al alojamiento y a la base de datos, concedido con las invitaciones de cada plataforma y no enviando contraseñas. Escribe en una página qué debe hacer la app, quién la usa y qué dolería más si fallara. Con esa hoja, una revisión de la seguridad del vibe coding lleva días y no semanas.
VITON13 Studio ofrece un paquete llamado Rescate de una app creada con IA. Incluye una revisión de seguridad del código y los ajustes, arreglos de lo que se rompe, configuración del despliegue y una limpieza del código para que el siguiente desarrollador pueda leerlo. Antes de cualquier pago, el estudio entrega un borrador gratuito: la lista de los principales problemas encontrados. El precio es fijo, desde $113, y el trabajo lleva de 5 a 10 días laborables.
Lista práctica
- Abre todas las direcciones privadas sin sesión y como usuario normal, y anota lo que carga.
- Busca claves en el repositorio y su historial; revoca las que encuentres y emite nuevas.
- Activa reglas por fila en cada tabla accesible desde el navegador y pruébalas con dos usuarios.
- Guarda las claves de producción en los ajustes del alojamiento y los datos reales aparte de los de prueba.
- Pide a alguien que no hizo la app una lista escrita de problemas ordenada por riesgo.
Preguntas frecuentes
¿Es seguro lanzar tal cual una app hecha con Cursor, Lovable, Bolt o v0?
No se puede dar por hecho. La herramienta busca que la app funcione, y nada garantiza que haya comprobado quién puede ver cada registro. Haz las pruebas de un día de este artículo y pide a alguien que no la hizo que revise el código y los ajustes antes de que lleguen clientes.
¿Qué hago si una clave de API se subió al repositorio?
Trátala como expuesta. Revócala primero con el proveedor, crea una nueva, guárdala en los ajustes del alojamiento, vuelve a desplegar y revisa los registros de uso por si hay actividad desconocida. Limpiar el historial de Git es un paso aparte y opcional, que viene después.
¿Basta con Row Level Security para proteger mi base de datos?
No. Según la documentación de Supabase, las tablas necesitan además permisos y políticas adecuados, y la clave secreta se salta RLS por completo. Mantenla fuera del código del navegador y prueba cada tabla con casos de permiso y denegación para cada rol.
¿Puedo arreglarlo pidiendo a la herramienta de IA que haga la app segura?
Puede ayudar con un problema concreto y nombrado, como añadir una comprobación de propietario en un endpoint. Una petición general deja huecos, porque la herramienta no ve los ajustes del alojamiento, las políticas de la base ni el historial del repositorio. Trata sus cambios como borradores y pruébalos.
¿Cuándo conviene reconstruir una app hecha con IA en lugar de repararla?
Cuando cada arreglo rompe otra cosa, la estructura de datos no encaja con el negocio o nadie sabe dónde están los datos. En los demás casos reparar suele costar menos. Una lista escrita de problemas ordenada por riesgo es la forma justa de comparar.