El OWASP Top 10 aplicado a apps hechas con IA
Cada riesgo del OWASP Top 10:2025 explicado en palabras simples, cómo aparece en apps de Lovable, Bolt, Cursor o Replit y qué revisar en la tuya.
Read in English →
El OWASP Top 10 es la lista de riesgos de seguridad web más usada del mundo, y su edición 2025 aplica a las apps hechas con Lovable, Bolt, Cursor, Replit o v0 igual que a las escritas a mano. En las apps hechas con IA se repiten casi siempre los mismos puntos: control de acceso roto (usuarios que llegan a datos ajenos), configuración insegura (reglas de base de datos abiertas, ajustes de prueba en producción), problemas en la cadena de dependencias y fallas de autenticación. Los demás también cuentan, pero por esos cuatro conviene empezar.
A continuación, cada una de las diez categorías con una explicación simple, la forma que suele tomar en una app hecha con IA y una o dos cosas que puedes revisar por tu cuenta.
¿Qué es el OWASP Top 10?
Es una clasificación que publica OWASP, una fundación sin fines de lucro, con los riesgos de seguridad más críticos para aplicaciones web, armada con datos de aplicaciones reales y una encuesta a la comunidad. No es una norma ni una certificación; es un vocabulario común para "lo que más suele salir mal". La lista vigente es el OWASP Top 10:2025.
A01 Control de acceso roto (Broken Access Control)
Qué significa: los usuarios pueden ver o hacer cosas que no les corresponden, como leer las facturas de otro cliente o ejecutar una acción de administrador.
En apps hechas con IA: es el problema grave más común. La interfaz esconde el botón, pero la base de datos o la API le responde a cualquiera que pregunte. Las tablas de Supabase sin Row Level Security, o con una política using (true), son el caso típico. La lista 2025 incluye aquí también el SSRF (hacer que tu servidor pida una URL elegida por un atacante).
Revisa: entra como el usuario A, copia el ID de uno de sus registros, entra como el usuario B y pídelo. Lo explicamos paso a paso en un usuario ve datos de otro.
A02 Configuración de seguridad incorrecta (Security Misconfiguration)
Qué significa: ajustes inseguros, no código con errores.
En apps hechas con IA: buckets de almacenamiento públicos, CORS abierto a cualquier origen, páginas de error detalladas en producción, la configuración de correo por defecto, una clave de prueba de Stripe en el sitio real, despliegues de vista previa con datos reales y sin contraseña.
Revisa: recorre cada panel que usas (base de datos, hosting, autenticación, almacenamiento) y lee uno por uno los ajustes de seguridad pensando en producción.
A03 Fallas en la cadena de suministro de software (Software Supply Chain Failures)
Qué significa: el riesgo que viene del código que no escribiste: paquetes, herramientas de build, plugins y los servicios que los distribuyen.
En apps hechas con IA: los agentes instalan paquetes con libertad, a veces abandonados, con el nombre mal escrito o que ni hacían falta. El lockfile se borra para "arreglar" un error de instalación.
Revisa: mira tu package.json y pregúntate para qué está cada dependencia. Deja el lockfile en Git, activa las alertas de dependencias en GitHub y desconfía de un paquete desconocido con muy pocas descargas.
A04 Fallas criptográficas (Cryptographic Failures)
Qué significa: datos que deberían estar protegidos y no lo están, por cifrado débil o inexistente.
En apps hechas con IA: casi siempre te lo resuelven (HTTPS del hosting, contraseñas cifradas por el proveedor de autenticación). Los problemas aparecen cuando la IA arma su propio sistema de login, guarda contraseñas o tokens en texto plano o mete campos sensibles en localStorage.
Revisa: si tu app tiene su propia tabla de contraseñas en lugar de un servicio de autenticación administrado, pide que la revisen.
A05 Inyección (Injection)
Qué significa: datos del usuario tratados como código o comandos, como la inyección SQL o el cross-site scripting (XSS).
En apps hechas con IA: SQL armado juntando textos en una función de servidor, contenido del usuario mostrado con dangerouslySetInnerHTML y, en las funciones con IA, la inyección de prompts, que vemos en inyección de prompts en tu app.
Revisa: busca en el código dangerouslySetInnerHTML, innerHTML y textos SQL con ${ adentro.
A06 Diseño inseguro (Insecure Design)
Qué significa: la falla está en cómo se pensó la función, no en cómo se programó.
En apps hechas con IA: un crédito por referido que se puede reclamar una y otra vez, una prueba gratis que se reinicia al cambiar de correo, un precio que manda el navegador y el servidor acepta, un enlace de invitación que nunca vence.
Revisa: en cada función que involucre dinero, créditos o permisos, pregúntate "¿qué pasa si alguien hace esto mil veces o cambia el número en la petición?".
A07 Fallas de autenticación (Authentication Failures)
Qué significa: debilidades en cómo los usuarios demuestran quiénes son.
En apps hechas con IA: intentos de inicio de sesión ilimitados, reglas de contraseña débiles, enlaces de recuperación que no vencen, sesiones que sobreviven a un cambio de contraseña, cuentas de administrador sin segundo factor. Mira nuestras guías para recuperar la contraseña de forma segura y sobre autenticación de dos factores.
Revisa: prueba el flujo de recuperación completo y confirma que el enlace sirve una sola vez.
A08 Fallas de integridad de software o datos (Software or Data Integrity Failures)
Qué significa: confiar en código o datos sin comprobar que nadie los alteró.
En apps hechas con IA: endpoints de webhook que no verifican la firma (cualquiera puede mandar un falso "pago exitoso"), scripts cargados desde CDN desconocidos, actualizaciones automáticas sin revisión.
Revisa: confirma que cada webhook verifica la firma del proveedor antes de hacer algo.
A09 Fallas de registro y alertas (Security Logging & Alerting Failures)
Qué significa: hay ataques o abusos y nadie se entera.
En apps hechas con IA: sin seguimiento de errores, sin registro de acciones de administrador, sin alertas cuando se disparan los registros o el uso de la IA.
Revisa: ¿podrías saber hoy quién cambió el rol de un usuario la semana pasada? En monitoreo y errores en producción proponemos una configuración liviana.
A10 Manejo incorrecto de condiciones excepcionales (Mishandling of Exceptional Conditions)
Qué significa: la app se comporta de forma insegura cuando algo falla: deja pasar ante un error, filtra detalles en los mensajes o deja datos a medio guardar.
En apps hechas con IA: una verificación de permisos dentro de un try/catch que deja pasar al usuario si algo falla, un flujo de pago que da acceso cuando el proveedor no responde, errores técnicos completos en pantalla.
Revisa: busca bloques catch que devuelven éxito y asegúrate de que el usuario vea mensajes genéricos mientras los detalles van a tus registros.
¿Por dónde empiezo?
| Si tu app tiene… | Empieza por |
|---|---|
| Cuentas de usuario y datos privados | A01, A02 |
| Pagos o créditos | A06, A08 |
| Un panel de administración | A01, A07 |
| Funciones con IA | A05 (inyección de prompts) y límites de uso |
| Muchos paquetes agregados por un agente | A03 |
Respuestas rápidas
¿Cumplir con OWASP es una certificación? No. El Top 10 es un documento de concienciación. Seguirlo es buena práctica, no un certificado.
¿Las herramientas de IA escriben código inseguro a propósito? No. Buscan que funcione en la vista previa, y muchos de estos riesgos solo aparecen cuando alguien usa la app con mala intención.
¿Puedo revisar los diez yo solo? Puedes revisar los síntomas de esta guía. Una revisión completa necesita a alguien que lea el código y las reglas de la base de datos. Nuestra guía para revisar código generado por IA ayuda con la primera pasada.
¿Y ahora qué?
El chequeo de salud gratis cubre lo que se ve desde afuera de tu app. Si quieres que una persona revise el control de acceso, las reglas de la base de datos y el resto de esta lista en tu código, mira nuestra revisión de seguridad de Supabase o escríbenos si usas otra tecnología.
