¿Es segura una aplicación hecha con IA? Cómo saberlo aunque no seas técnico

Por Kike Gandia · Co-Fundador y CEO, OSCP

Construir una aplicación con Lovable, Bolt, v0, Replit o un copiloto como Cursor o Copilot ha dejado de ser raro. Lo que casi nunca ocurre es que alguien compruebe si esa aplicación es segura antes de ponerla delante de usuarios reales. Y hay una diferencia importante entre "funciona" y "es segura": lo primero lo verifica cualquiera abriéndola en el navegador; lo segundo requiere mirar dónde nadie mira. Esta guía explica qué falla en la práctica, por qué falla y cómo comprobar en poco tiempo si tu aplicación tiene un problema.

Por qué una app generada con IA puede funcionar y estar expuesta

Los modelos generan código que cumple el objetivo que les pides. Tú pides "que los usuarios puedan guardar sus notas", y el resultado guarda notas. Lo que no le pides —porque no se te ocurre que haya que pedirlo— es que un usuario no pueda leer las notas de otro.

Esa asimetría es el origen de casi todos los problemas. La funcionalidad se prueba sola: si no funciona, lo ves. La seguridad no se prueba sola: si está mal, la aplicación sigue funcionando exactamente igual. Nada se rompe, nada avisa, y el fallo solo se manifiesta cuando alguien lo busca.

A esto se suma un segundo factor: los generadores optimizan para que veas resultados rápido. Eso implica configuraciones permisivas por defecto en la capa de datos y en los permisos, pensadas para que nada te bloquee mientras construyes. Cerrarlas es responsabilidad de quien publica la aplicación, y es el paso que casi nadie da.

La diferencia entre un copiloto y un generador de aplicaciones

No es lo mismo haber usado GitHub Copilot o Cursor que haber usado Lovable, Bolt, v0 o Replit, y la auditoría cambia según el caso.

Con un copiloto existe un repositorio y alguien que, al menos, ha leído el código. Los fallos son de código: inyecciones, validación insuficiente, secretos escritos a mano, dependencias inseguras. Se parecen a los de cualquier desarrollo tradicional hecho con prisa.

Con un generador de aplicaciones puede que no haya nadie que haya leído el código, y el fallo rara vez está en una línea concreta: está en la configuración. La base de datos accesible desde el navegador, los permisos entre usuarios sin definir, las claves de servicios de terceros incrustadas en el front. Aquí revisar solo el código no sirve de nada: hay que mirar la aplicación desplegada.

La consecuencia práctica es que si construiste con un generador y alguien te ofrece "una revisión del repositorio", te está ofreciendo la mitad del trabajo.

Las tres preguntas que deciden si tienes un problema

Antes de entrar en detalle técnico, tres preguntas separan una aplicación razonablemente cerrada de una expuesta.

1. ¿Puede un usuario ver los datos de otro? Crea dos cuentas, mete datos distintos en cada una y comprueba desde la primera si puedes acceder a lo de la segunda cambiando un identificador en la URL o en una petición. Si puedes, tienes un problema grave y barato de arreglar.

2. ¿Hay claves en el navegador? Abre las herramientas de desarrollo, pestaña de red, y mira qué se envía. Si ves credenciales de base de datos, claves de API de pago o tokens que no sean públicos por diseño, están al alcance de cualquiera.

3. ¿Quién puede escribir en tu base de datos? Es la pregunta que menos gente se hace y la que peores consecuencias tiene. Una base de datos que acepta escrituras sin comprobar quién las hace permite borrar o alterar datos de todos los usuarios, no solo leerlos.

Qué pasa si lo dejas como está

El riesgo no es abstracto. Una aplicación con la capa de datos abierta expone todo lo que contiene: correos, nombres, contenido subido por los usuarios y, según el producto, datos de pago o información de salud. No hace falta un ataque sofisticado; basta con que alguien mire.

Si esos datos incluyen información personal de residentes en la UE, estás además ante una brecha con obligaciones concretas: notificación a la autoridad de control en 72 horas y, según el impacto, comunicación a los afectados. El RGPD no distingue entre un fallo introducido por un desarrollador y uno introducido por un generador de código.

Y hay un coste comercial que llega antes que el regulatorio: en cuanto vendes a otra empresa, tu cliente va a preguntar por la seguridad de tu producto. Lo mismo si levantas inversión. Llegar a esa conversación sin haber revisado nada es la forma más rápida de perder el trato.

Qué hacer ahora, en orden

No hace falta parar el producto ni rehacerlo. El orden que más riesgo elimina por unidad de esfuerzo es este:

1. Cierra la capa de datos. Activa las reglas de acceso por fila y comprueba que nadie sin autenticar puede leer ni escribir.
2. Saca los secretos del front. Cualquier clave que no esté pensada para ser pública tiene que vivir en el servidor.
3. Comprueba la autorización entre usuarios, no solo el login. Autenticar es saber quién eres; autorizar es saber qué puedes tocar.
4. Revisa qué guardas de verdad. Mucha aplicación generada almacena más datos de los que necesita, y cada dato de más es superficie de exposición.
5. Pide una revisión externa antes de un lanzamiento o de una due diligence, no después.

Los tres primeros puntos los puede hacer quien construyó la aplicación en una tarde. El cuarto y el quinto requieren mirar con criterio de atacante.

FAQ

¿Es menos segura una app hecha con IA que una hecha por un programador?

No por naturaleza, pero sí con más frecuencia. El código generado por modelos reproduce patrones inseguros presentes en sus datos de entrenamiento, y quien lo publica muchas veces no tiene criterio para detectarlos. Un programador con experiencia comete menos fallos de configuración básica; uno con prisa comete los mismos. La diferencia real no es la herramienta, es si alguien ha revisado el resultado con criterio de seguridad.

Mi aplicación es pequeña y tiene pocos usuarios, ¿me afecta igual?

El tamaño no te protege. Los escaneos que descubren bases de datos abiertas son automáticos e indiscriminados: recorren rangos enteros de internet sin saber ni a quién pertenece cada servicio. Una aplicación con veinte usuarios y la capa de datos abierta se encuentra igual de rápido que una con veinte mil. Lo que cambia con el tamaño es el impacto, no la probabilidad.

¿Puedo comprobarlo yo mismo o necesito a alguien externo?

Las tres comprobaciones de esta guía las puede hacer cualquiera con el navegador abierto, y descartan los fallos más graves y más comunes. Lo que no cubren es la lógica de negocio: que un usuario pueda aplicarse un descuento que no le corresponde, cambiar el estado de un pedido ajeno o escalar a administrador por un camino no previsto. Eso exige alguien que ataque la aplicación con intención, porque no se detecta mirando.