Los 7 fallos de seguridad que más repiten las aplicaciones generadas con IA

Por Kike Gandia · Co-Fundador y CEO, OSCP

Cuando se auditan aplicaciones construidas con generadores o con asistentes de código, los hallazgos se repiten con una regularidad llamativa. No son fallos exóticos ni cadenas de explotación sofisticadas: son siempre las mismas configuraciones que nadie cerró. Esta es la lista, ordenada por la frecuencia con que aparece y por el daño que causa, con la comprobación concreta que permite descartar cada uno.

Resumen: los siete fallos y cómo comprobarlos

Cada fila se puede verificar sin herramientas especiales, solo con el navegador y dos cuentas de prueba.

Fallo	Cómo comprobarlo	Consecuencia si está abierto
Base de datos sin reglas por fila	Consultar la API de datos sin estar autenticado	Toda la base de datos legible
Autorización entre usuarios ausente	Cambiar un identificador en la URL desde otra cuenta	Ver y editar datos ajenos
Claves de terceros en el front	Pestaña de red de las herramientas de desarrollo	Uso de tu cuenta de pago o correo a tu costa
Buckets de ficheros abiertos	Abrir la URL de un fichero subido sin sesión	Descarga masiva de documentos de usuarios
Endpoints de administración sin proteger	Probar rutas tipo /admin sin sesión	Control total de la aplicación
Registro abierto sin verificación	Crear una cuenta con un correo inexistente	Abuso, spam y cuentas fantasma
Errores que revelan la estructura interna	Forzar un error con datos inválidos	Mapa de la base de datos servido al atacante

1 y 2. La capa de datos: el fallo que lo domina todo

Los dos primeros son en realidad el mismo problema visto desde dos ángulos, y juntos explican la mayoría de las filtraciones en aplicaciones generadas.

Los generadores conectan la aplicación directamente a la base de datos desde el navegador. Eso es una decisión de diseño legítima y muy práctica: el front habla con la base de datos sin servidor intermedio. Pero solo funciona con seguridad si las reglas de acceso por fila están definidas, porque son lo único que separa a un usuario de los datos de todos los demás.

Cuando esas reglas no se activan, cualquiera que abra las herramientas de desarrollo ve la dirección de la base de datos y la clave con la que el front se conecta, y puede pedirle los datos directamente. No hace falta vulnerar nada: la aplicación entrega la información porque está configurada para entregarla.

El segundo ángulo es más sutil y sobrevive a la primera corrección: aunque exijas autenticación, si la regla no comprueba de quién es cada registro, cualquier usuario registrado puede leer los de los demás. Autenticar no es autorizar.

3 y 4. Lo que se queda en el navegador

Todo lo que el front necesita para funcionar viaja al navegador del usuario, y ahí es público por definición. La confusión habitual es asumir que algo "no se ve" porque no aparece en la interfaz.

Claves de terceros. Claves de Stripe, de servicios de correo transaccional o de APIs de pago que deberían vivir en el servidor acaban en el bundle de front porque era la forma rápida de que funcionara. Quien las encuentre puede emitir cargos, enviar correo en tu nombre o consumir tu cuota.

Buckets de ficheros. Las facturas, los justificantes y las imágenes que suben los usuarios se guardan con reglas permisivas por defecto. Si la URL de un fichero es adivinable o simplemente no exige sesión, se pueden descargar todos. Es el fallo con peor lectura reputacional, porque el contenido suele ser documentación personal.

5, 6 y 7. Los que se descubren solos

Endpoints de administración sin proteger. El generador crea un panel para que tú gestiones la aplicación y a veces protege la interfaz pero no la ruta de datos que hay detrás. Comprobarlo es abrir esa ruta sin sesión iniciada.

Registro abierto sin verificación de correo. Parece menor y no lo es: permite crear cuentas en masa, y si el producto reparte cuota gratuita o envía correos, se convierte en un coste directo y en un problema de reputación de tu dominio de envío.

Errores que revelan la estructura interna. Cuando algo falla, muchas aplicaciones generadas devuelven el error de la base de datos tal cual, con nombres de tablas y columnas. Para un atacante es un mapa gratuito: le ahorra la parte lenta del trabajo. La corrección es trivial —capturar los errores y devolver un mensaje genérico— y casi nunca está hecha.

Qué corregir primero

Si solo puedes hacer una cosa esta semana, activa las reglas de acceso por fila y comprueba que exigen propiedad del registro, no solo sesión. Ese único cambio cierra los dos fallos que causan la mayor parte de las filtraciones reales.

Después, saca del front cualquier clave que no esté pensada para ser pública y revisa las reglas de los buckets. Los tres últimos fallos de la lista son más baratos de arreglar y menos urgentes, pero conviene cerrarlos antes de cualquier revisión externa: son los que peor impresión causan en una due diligence, porque delatan que nadie miró.

FAQ

¿Estos fallos son culpa del generador que he usado?

No. Son configuraciones que la herramienta deja abiertas para que puedas construir sin fricción y que corresponde cerrar a quien publica la aplicación. Lovable, Bolt, v0, Replit y Supabase documentan cómo hacerlo y avisan de ello. El problema es que quien construye sin perfil técnico no siempre entiende que ese aviso le aplica, y el producto funciona igual de bien si lo ignora.

¿Cuántos de estos siete suele tener una aplicación real?

Lo habitual es encontrar varios a la vez, porque tienen una causa común: nadie revisó la configuración después de que la aplicación empezara a funcionar. Es raro encontrar una aplicación generada con un único fallo aislado, y es igual de raro encontrarla con los siete: lo normal está en medio, y casi siempre incluye al menos uno de los dos primeros.

Ya he corregido la capa de datos, ¿necesito igualmente una auditoría?

Esta lista cubre los fallos de configuración, que son los más frecuentes y los que se detectan desde fuera. No cubre la lógica de negocio de tu producto: precios que se pueden manipular, flujos de estado que se pueden saltar, permisos que se pueden escalar por un camino no previsto. Eso es específico de cada aplicación y no aparece en ninguna lista genérica.