Las 5 vulnerabilidades que probablemente tenga tu app creada con IA (y cómo encontrar cada una)
Tu app hecha con IA funciona, se ve bien, incluso está captando clientes — pero la IA no te avisó que dejó puertas abiertas. Inspirado en el video de Mano Devin, esta guía enumera las 5 fallas más comunes en apps creadas con Vibe Coding y muestra herramientas gratuitas para encontrar y cerrar cada brecha.
Lanzar un SaaS con Vibe Coding es casi un rito de iniciación para los desarrolladores independientes hoy en día. Herramientas como Cursor, Claude Code, Lovable y Bolt entregan una app funcionando en horas. Pero lo que la IA no te cuenta es que podría estar dejando varias puertas abiertas en el camino.
El canal Mano Devin, una referencia en seguridad para desarrolladores brasileños, publicó un video imperdible analizando los cinco errores más comunes en apps creadas con IA — y lo peor: están presentes en apps serias, de empresas grandes, no solo en proyectos de fin de semana.
El problema no es la IA. El problema es que optimiza para "funcionar", no para "resistir ataques".
A continuación, las 5 vulnerabilidades, explicadas con ejemplos reales, y cómo tú mismo puedes encontrar cada una — gratis.
1. RLS desactivado — la caja fuerte sin puerta
Si usas Supabase o Firebase, tu base de datos se comunica directamente con el navegador. No hay un servidor backend que proteja la transacción de datos. La protección en este modelo se llama RLS (Row Level Security): un bloqueo que garantiza que cada usuario solo vea sus propios datos.
¿El problema? El RLS viene desactivado por defecto. Es como comprar una caja fuerte imponente, ponerla en la oficina, pero dejar la puerta sin llave.
Dato real: El 83% de las filtraciones de Supabase están relacionadas con RLS mal configurado o desactivado, según un estudio de 2025. Una CVE del año pasado expuso datos de más de 170 aplicaciones a la vez.
Y lo peor: Yuri Dev mostró un caso donde la persona simplemente pidió la base de datos de la aplicación — y la base de datos la entregó. Nombres de distribuidores, WhatsApp, tiendas. Sin contraseña, sin intrusión. Solo la pidió.
Cómo encontrar: Accede al panel de Supabase, ve a SQL Editor y ejecuta SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';. Las tablas con rowsecurity = false están desbloqueadas.
Cómo resolver: Activa el RLS en cada tabla y crea políticas de acceso. Una línea de SQL lo resuelve.
2. Permiso de admin en el frontend — el localStorage que decide quién manda
Esta es clásica y sorprendentemente común. La app define si el usuario es administrador o no directamente en el frontend, generalmente en el localStorage del navegador.
Yuri Dev lo demostró: abrió Inspeccionar Elemento, cambió admin: false a admin: true en localStorage, recargó y accedió al panel administrativo. El caso más famoso fue el del influencer Riter (22 millones de seguidores), donde una sola palabra modificada en localStorage liberó cursos enteros que ni siquiera habían sido lanzados.
Regla de oro: la lógica de negocio vive en el backend, no en el frontend. El frontend solo renderiza. Si dejas que el navegador decida quién es admin, el navegador se convierte en el mejor amigo del hacker.
Cómo encontrar: Abre las DevTools de tu navegador (F12), ve a Application > Local Storage y busca campos como admin, role, isAdmin, userType. Si están en el frontend y el backend confía ciegamente en ellos, tienes una falla.
Cómo resolver: Toda verificación de permiso debe ser validada en el servidor. El frontend puede mostrar u ocultar botones, pero el backend es quien decide si la solicitud está autorizada.
3. IDOR — el mostrador de la farmacia que entrega datos de todo el mundo
IDOR (Insecure Direct Object Reference) es una de las fallas más fáciles de explotar y más ignoradas por el Vibe Coding. La lógica es simple:
Imagina un mostrador de farmacia. Llegas y dices "pedido 105". El dependiente lo entrega. Dices "pedido 106". También lo entrega. 107, 108... En 5 minutos te llevaste los pedidos de toda la calle.
Eso es exactamente lo que sucede cuando una ruta como /api/user/3 devuelve los datos del usuario 3 sin verificar si tú eres el usuario 3. El atacante cambia el número en la URL y obtiene los datos del vecino: teléfono, saldo, correo electrónico.
Cómo contribuye la IA: Cuando pides "crea un CRUD de usuarios" o "ruta de búsqueda de pedido por ID", la IA genera exactamente eso — un endpoint que busca por ID, sin verificar si el ID pertenece a la persona logueada. Si no pides esta verificación, no se incluirá.
Esta es la #1 de la lista OWASP de fallas de API.
Cómo encontrar: Usa OWASP ZAP (herramienta gratuita). Dale la dirección de tu app, y empezará a atacar todas las rutas y a probar variaciones de ID.
Cómo resolver: Siempre verifica si el recurso solicitado pertenece al usuario autenticado. Nunca confíes en el ID que el cliente envió sin validar la propiedad.
4. Claves de API hard-coded — el secreto que se hizo público
Este es el error que entrega la contraseña de tu aplicación a cualquiera que abra el Inspeccionar Elemento.
Toda integración (pasarela de pago, correo electrónico, almacenamiento en la nube) proporciona una clave de API. Esta clave debe permanecer en el servidor, en una variable de entorno. Pero la IA, si te descuidas, simplemente la codifica directamente en el código.
Y lo peor: cuando haces el build del frontend, toda variable se convierte en JavaScript público. Cualquiera puede leerla abriendo las DevTools.
Solo en 2024, 24 millones de secretos se filtraron de esta forma, según un estudio de seguridad. Los bots rastrean GitHub en tiempo real en busca de claves expuestas.
Yuri Dev mostró el caso de un estafador que encontró la clave de la pasarela de pago dentro de un archivo público en GitHub. En sus palabras: "el estafador nunca oyó hablar de .gitignore".
Cómo encontrar: Usa Gitleaks (gitleaks detect --source .) para escanear tu repositorio en busca de claves, contraseñas y tokens filtrados en el historial de Git. Aunque los hayas borrado después, el historial los guarda.
Cómo resolver: Las claves de API nunca van en el frontend. Usa variables de entorno (process.env.API_KEY) en el servidor, y endpoints proxy en el backend para cualquier servicio externo.
5. XSS — la característica que era una falla
Esta es la más traicionera porque no parece una falla — parece una característica.
El caso de Riter: el curso tenía un campo de "HTML personalizado" en el panel, que permitía escribir código que se ejecutaba en todas las páginas. Y en la subida de perfil, aceptaba cualquier archivo. Enviaron una imagen con un script oculto dentro y robaron la sesión del admin.
Esto se llama XSS (Cross-Site Scripting). El usuario escribe código en lugar de texto, y el sitio ejecuta ese código, creyendo que era contenido legítimo.
El 45% del código generado por IA tiene fallas de este tipo, según Veracode. Casi la mitad.
La regla es simple: en un sistema seguro, todo lo que el usuario escribe es mentira hasta que se demuestre lo contrario. Trata la entrada como hostil.
Cómo encontrar: Usa OWASP ZAP (que tiene un escáner de XSS automático) o TruffleHog (fork de código abierto del proyecto Srap). Ambos son gratuitos.
Cómo resolver: Valida, sanitiza y limita toda entrada del usuario. Nunca confíes en que el contenido es seguro solo porque provino de un campo de texto.
Cómo ecoa.dev te ayuda a cerrar estas brechas
ecoa.dev fue hecho exactamente para llenar esta brecha entre "app funcionando" y "app seguro".
El Scan Service de ecoa.dev realiza un escaneo completo en minutos:
- Descubre endpoints sensibles expuestos (
.env,.git, paneles administrativos) - Verifica encabezados de seguridad (HSTS, CSP, cookies seguras)
- Prueba redireccionamiento HTTPS forzado, SSL/TLS
- Detecta vulnerabilidades como SSRF e inyección
Además, el LGPD Analyzer verifica si tu app cumple con la ley brasileña — política de privacidad, cookies, canal del titular. El tipo de checklist que ninguna herramienta de Vibe Coding genera por sí misma.
Y cuando el escaneo encuentra una falla, ecoa genera un prompt de corrección listo para que lo pegues de nuevo en tu herramienta de IA favorita. No necesitas entender de seguridad profunda: es copiar, pegar en Cursor o Claude, y la IA ajusta el código.
Prueba tu app en ecoa.dev antes de que alguien más lo haga por ti.