Por qué las apps construidas con IA salen inseguras

“Un contratista que construye exactamente lo que le describes, rápido, y nunca menciona el código de edificación, porque no se lo pediste.”

La brecha entre 'funciona' y 'es seguro'

Pídele a una herramienta de IA que construya una funcionalidad y optimizará para lo que puedes ver: la pantalla se renderiza, el botón envía, los datos aparecen. Esa es la demo, y la demo pasa. La seguridad es la parte que no puedes ver en la demo: la comprobación de que un usuario no puede leer los datos de otro, la clave que no debería estar en el navegador, el endpoint que debería rechazar una petición no autenticada. Nada de eso cambia el aspecto del camino feliz, así que nada de eso se construye a menos que alguien lo pida.

Esto no es una crítica a las herramientas. Es una descripción de aquello para lo que fueron entrenadas: producir código que satisfaga la petición. "Constrúyeme un panel donde los usuarios vean sus pedidos" produce un panel donde los usuarios ven sus pedidos. No produce "…y donde el usuario A demostrablemente no pueda alcanzar los pedidos del usuario B", porque no lo dijiste, y en la demo, con un solo usuario conectado, la diferencia es invisible.

Por qué el modelo deja los agujeros

Tres fuerzas se acumulan. El modelo rellena con el patrón más común de sus datos de entrenamiento, y buena parte de esos datos son tutoriales y código de inicio rápido que nunca se pensaron para producción. No tiene visión de tu modelo de amenazas: no sabe si esto es un proyecto de fin de semana o si maneja datos de pago. Y cada ronda de prompting puede deshacer en silencio una salvaguarda de una ronda anterior, porque el modelo optimiza la petición actual, no la preservación de la última. Por qué pasar la demo no te dice nada sobre la seguridad.↗

Una brecha real, en detalle

En 2025 un investigador de seguridad, Matt Palmer, rastreó 1.645 aplicaciones construidas en la plataforma de IA Lovable y encontró 303 endpoints inseguros en 170 de ellas (aproximadamente una de cada diez) donde cualquiera podía leer, modificar o borrar cualquier fila de la base de datos. Los datos expuestos incluían nombres, números de teléfono, datos de pago y claves de API. La causa raíz no era exótica: las apps generadas hablaban con su base de datos directamente desde el navegador sin reglas de acceso a nivel de fila. Se convirtió en el CVE-2025-48757, calificado como crítico (CVSS 9.3).

Nada en esas 170 apps parecía roto. Se lanzaron, funcionaban, usuarios reales se registraron. El agujero era estructural e invisible desde el front end, exactamente el tipo de brecha del que trata este curso. Las cifras que circulan junto a historias como esta ("X millones de claves filtradas") suelen estar sin verificar; el CVE documentado basta por sí solo para demostrar el punto.

Los cinco agujeros, y el resto de este curso

La buena noticia: los agujeros no son infinitos ni misteriosos. Las apps construidas con IA se filtran en un pequeño número de lugares predecibles, y cada uno corresponde a un capítulo:

• Acceso a datos: la base de datos confía en el navegador, así que cualquier usuario puede alcanzar cualquier fila (capítulo 2).
• Secretos: las claves de API y credenciales acaban en código de cliente o en git (capítulo 3).
• Autorización: el login existe, pero las comprobaciones de propiedad por recurso no (capítulo 4).
• Superficie expuesta: endpoints olvidados, APIs abiertas y webhooks sin verificar (capítulo 5).
• Todo lo demás antes de lanzar: cabeceras, dependencias, errores y la checklist que atrapa el resto (capítulo 6).

Recórrelos en orden y cerrarás las brechas que produjeron incidentes como el CVE de Lovable. Nada de esto requiere ser especialista en seguridad. Requiere conocer los cinco lugares donde mirar y qué significa "terminado" en cada uno.