Escaneo de seguridad para código generado por IA: DAST para apps vibe-coded

Por qué el código generado AI- necesita un análisis de seguridad diferente

Las herramientas de codificación AI están entrenadas en repositorios de código abierto a escala. Esos datos de entrenamiento se inclinan hacia make it work sobre make it secure. De ahí se derivan algunos patrones estructurales:

• Autocomplete bias. La importación coincidente más cercana gana. Pegar un fragmento Supabase que usa la clave service_role en un archivo hace que esa clave sea la sugerencia de autocompletar en el siguiente, incluso en componentes de React del lado del cliente donde nunca perteneció.
• No long-term context. Un LLM no recuerda tu último RLS bypass ni el incidente post mortem de tu equipo. Cada archivo generado es nuevo y a menudo faltan patrones defensivos que los humanos llevarían a través de los archivos.
• Speed as the rewarded metric. Los usuarios elogian la velocidad; El entrenamiento LLM lo refuerza. "Generar la autenticación Next.js más rápida" supera a "generar la autenticación Next.js más segura" en señales de retroalimentación de latencia.
• Training data gaps. Las bases de código más antiguas dominan los datos de entrenamiento y son anteriores a los valores predeterminados de seguridad modernos (estrictos CSP, SameSite=Lax, HSTS, RLS). El código generado refleja patrones que eran normales en 2019 pero que hoy son inseguros.
• Implicit platform trust. Cuando Cursor genera una aplicación Vercel, asume que los valores predeterminados de Vercel son seguros. Algunas son (auto-HTTPS, cookies firmadas). Muchos no lo son (no CSP de forma predeterminada, permisivo CORS, rutas de depuración predeterminadas Next.js).

Diez clases de vulnerabilidad sobrerrepresentadas en aplicaciones codificadas por vibración

En miles de escaneos de aplicaciones generadas por AI-, las mismas clases de búsqueda aparecen de manera desproporcionada:

1. Exposed Supabase service-role keys. Un service_role JWT (comienza eyJ) comprometido con un paquete de cliente omite todas las políticas RLS del proyecto. Cursor lo autocompleta en el lado equivocado del límite; la clave se envía en /_next/static/....
2. Missing Row-Level Security (RLS). El modelo ve CREATE TABLE public.items y continúa sin habilitar RLS. Los usuarios anónimos pueden leer o escribir cualquier fila mediante la clave pública anónima. Ver baas.supabase-rls.
3. Open Firebase / Firestore rules. Los archivos de reglas generados a menudo dicen allow read, write: if true; u omiten el archivo de reglas por completo. Las reglas predeterminadas del modo de prueba caducan después de 30 días y bloquean la base de datos, pero sólo si el desarrollador se da cuenta.
4. Hardcoded API keys in bundles. Stripe claves en vivo, Anthropic sk-ant-*, OpenAI sk-*, Google AIza* y AWS AKIA* terminan alineadas en las cargas útiles JS cuando la disciplina env-var caduca. secrets.browser-storage los marca en el nivel de página renderizada.
5. Missing Content Security Policy. Sin encabezado de respuesta Content-Security-Policy significa que cada script en línea XSS está a un clic de tomar el control total de la cuenta. CSP es abstracto; Codegen lo omite habitualmente. headers.security-headers informa la brecha con una guía de solución específica para la plataforma de implementación.
6. Next.js middleware misplacement. Con el diseño src/, Next.js solo selecciona src/middleware.ts; un middleware.ts de nivel raíz se ignora silenciosamente. La autenticación todavía parece funcionar porque las páginas llaman a requireAuth(), pero los encabezados, CSP y los límites de velocidad no aparecen.
7. Los controladores IDOR via unsigned IDs. generados GET /api/items/[id] confían en el parámetro de ruta y nunca verifican la propiedad. Caminar por el espacio entero o UUID expone los datos de cada inquilino.
8. Broken auth flows. Fichas de enlace mágico sin expires_at; JWT verificación que omite aud y exp; llamadas getSession() del lado del cliente (que leen una cookie no verificada) en lugar de getUser() del lado del servidor.
9. Debug endpoints in production. Las rutas /api/debug, /api/health, /api/__nextjs_original-stack-frame o /.next/trace generan fugas internas. discovery.platform-vercel los prueba con validación de contenido para evitar falsos positivos en las alternativas de SPA.
10. Plaintext sensitive fields. Contraseñas, claves API y PII almacenadas como texto sin formato en Postgres porque la migración no llegó a pgcrypto ni a una bóveda externa.

DAST vs SAST: por qué ambos son importantes para el código generado por AI-

El análisis estático (SAST) y el análisis dinámico (DAST) son complementos, no sustitutos. La división es más importante para el código generado por AI- que para el código escrito a mano.

SAST lee el código fuente en el disco. Detecta secretos en archivos fuente, llamadas a funciones peligrosas y patrones riesgosos antes de que se ejecute la compilación. No puede ver la configuración del tiempo de ejecución, las variables de entorno implementadas ni cómo un paquete transformó su código.

DAST accede a la aplicación implementada como un usuario. Ve las respuestas enviadas, se ejecuta en el paquete de producción y detecta la desviación de la configuración entre el repositorio y la implementación. Encuentra claves codificadas en JavaScript transpilado que SAST nunca vio porque ingresaron a través de una tarea process.env en el momento de la compilación.

For AI-generated code, DAST is essential porque lo que se envía difiere de lo que escribió el modelo. La agrupación, la sacudida de árboles, la transpilación y la alineación de variables ambientales crean nuevas superficies. SAST en la fuente puede pasar por alto por completo los secretos integrados en el paquete. DAST captura ambas capas. Una canalización madura ejecuta SAST en CI y DAST con la vista previa implementada; ese es el patrón FixVibe.

Qué buscar en un escáner de códigos AI-

La mayoría de los escáneres DAST de uso general (Burp Suite, OWASP ZAP, Nessus) fueron diseñados para aplicaciones monolíticas y flujos de autenticación tradicionales. Escanear una aplicación generada Vercel + Supabase + Stripe AI- necesita:

• BaaS coverage. Real verifica contra Supabase RLS, Firebase / reglas de Firestore, configuración de Clerk, AWS Amplify y las formas JWT que emiten esos servicios. Las reglas genéricas OWASP no saben qué marcar.
• JS bundle inspection. Expresión regular ajustada para API- formatos de clave, tokens firmados y patrones específicos del proveedor (Stripe sk_live_, antrópico sk-ant-, Supabase JWTs a partir de eyJ). Las heurísticas de entropía genérica arrojan demasiados falsos positivos.
• Passive + active split. Las comprobaciones pasivas (encabezados, cookies, secretos, configuración BaaS, DNS) se ejecutan de forma segura contra cualquier URL. Las sondas activas (SQLi, XSS, SSTI, IDOR caminando) requieren un límite de autorización porque disparan cargas útiles de estilo ataque.
• Framework awareness. Reconociendo Next.js App Router vs Pages Router, Vite SPA reescrituras, Vercel protección de implementación, Cloudflare enrutamiento de páginas. Un escáner que no distingue un Vite SPA alternativo de un /_next/build-manifest.json real genera ruido.
• Rate-limit safety. Presupuestos de solicitud limitados por escaneo, comparación de respuesta de referencia para evitar WAF-falsos positivos confusos, líneas de base de sonda de ruta aleatorias para detectar implementaciones generales de 403.
• Authorization gating for intrusive payloads. Enviar cargas útiles de comando SQLi o OS- a un dominio que no es de su propiedad es ilegal en la mayoría de las jurisdicciones. Un escáner real requiere DNS o HTTP- verificación de propiedad del archivo antes de permitirle ejecutar el modo activo contra un objetivo.

Enfoque de FixVibe: escaneo basado en evidencia, baja carga de falsos positivos

FixVibe is a DAST built specifically for AI-generated web apps. The passive phase runs 200+ checks on the rendered page (headers, CSP, cookies, leaked secrets, BaaS misconfiguration, tech fingerprinting, DNS, attack-surface discovery). The active phase adds payload-firing probes (SQLi, XSS, SSTI, CORS, redirects, IDOR walking, CSRF, account enumeration, blind-SSRF) gated behind verified-domain ownership. Repo scans add code-phase checks against connected GitHub repositories. Every finding includes evidence, a CWE link, a remediation recipe, and either a coding-agent prompt or operator steps depending on who can actually apply the fix. The scan engine is open in the changelog — every new check, accuracy improvement, and false-positive fix is logged publicly.

FixVibe vs Burp Suite, ZAP y Nessus: cuando cada herramienta gana

Ninguna herramienta cubre todos los flujos de trabajo. El encuadre honesto de dónde encaja FixVibe:

Donde las herramientas se complementan

• Start with FixVibe passive como referencia gratuita de 30 segundos frente a cualquier vista previa de implementación. Si no surge nada, tienes una rápida señal de confianza.
• Move to FixVibe active en un dominio verificado cuando desee una cobertura activa completa (SQLi/SSTI/IDOR/etc.) contra su propia infraestructura.
• Layer SAST (Semgrep, CodeQL, Snyk) en el código fuente en CI. SAST detecta lo que el tiempo de ejecución no puede ver: patrones riesgosos en rutas de código que nunca llegan a la implementación.
• Reach for Burp Suite cuando necesita cadenas de ataque personalizadas (omisiones de autenticación específicas, escenarios IDOR intrincados, fallas en la lógica empresarial). Burp es el banco de trabajo manual más profundo disponible; FixVibe es la línea de base automatizada más rápida.

Próximos pasos

Continue con Vibe coding security checklist para una auditoría previa al envío de 44 elementos, o salte a How to secure an app built with AI coding tools para un endurecimiento paso a paso con fragmentos de código.