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

The same finding classes show up disproportionately in AI-generated apps:

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 Supabase Row-Level Security.
3. Open Firebase / Firestore rules. Generated rules files often read allow read, write: if true; or skip the rules file entirely. Test-mode rules let anyone read and overwrite data until someone replaces them.
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 in JavaScript Bundles 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. HTTP 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. Generated /api/debug, /api/health, /api/__nextjs_original-stack-frame, or /.next/trace routes leak internals. FixVibe reports them only with evidence that they really are exposed (Vercel-Specific Exposure).
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. Recognising real API-key formats — Stripe sk_live_, Anthropic sk-ant-, Supabase service-role keys — and telling a secret key from a publishable one. Generic pattern matching throws too many false positives.
• 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. Recognising Next.js App Router vs Pages Router, Vite SPA rewrites, Vercel deployment-protection, Cloudflare Pages routing. A scanner that doesn't understand how these platforms answer unknown paths generates noise.
• Rate-limit safety. Bounded request budgets per scan, and findings that require positive evidence — a blanket 403 from a WAF is not proof a file exists.
• 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 230+ 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

No single tool covers every workflow. For a sourced side-by-side of FixVibe, Burp Suite, ZAP, Snyk, Semgrep and Aikido, with a decision matrix, see choosing a security scanner for AI-built apps.

Donde las herramientas se complementan

• Start with FixVibe passive as a free baseline against any deploy preview — it usually finishes in under a minute. If nothing surfaces, you have a fast confidence signal.
• 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 51 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.