Guía de Seguridad para Developers que Usan IA — Sin Conocimiento Previo

Esta guía de seguridad para developers que usan IA parte de un hecho incómodo: el 45% del código generado por IA tiene al menos una vulnerabilidad. No porque la IA sea mala programando. Sino porque optimiza para que el código funcione — no para que sea seguro.

Si usas Cursor, Bolt, Claude o cualquier otra herramienta de vibe coding, esta guía te explica exactamente qué revisar antes del deploy. Sin asumir conocimiento previo de seguridad.

Por qué el código generado por IA tiene vulnerabilidades

La IA no tiene un modelo de amenazas. No sabe quién va a atacar tu app ni cómo. Cuando le pides que genere un endpoint de pagos, genera un endpoint que funciona. Si no le dijiste "verifica que el usuario esté autenticado antes de procesar", no lo hace.

No es descuido — es que eso no era parte del problema que resolvió.

El resultado es código limpio, funcional, y con huecos que alguien más va a encontrar antes que tú. El reporte State of Software Security 2025 de Veracode documentó este patrón en proyectos reales, y la investigación de Tenzai sobre herramientas de vibe coding encontró un promedio de 69 vulnerabilidades por herramienta testeada.

La solución no es dejar de usar IA. Es agregar un paso de revisión que la IA no puede hacer por sí sola.

Paso 1: Asegura tus secretos antes que nada

Este es el error más común y el más caro. La IA inlinea API keys porque tú se las diste en el prompt o porque vio ese patrón en su entrenamiento.

// MAL: tu key de Stripe está en el código fuente
const stripe = new Stripe("sk_live_abc123xyz");
 
// BIEN: léela desde variables de entorno
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

Hay tres cosas que hacer ahora mismo:

Revisa tu historial de Git. Cambiar el valor en tu archivo .env no borra lo que ya commiteaste. Si alguna vez pusiste una key directamente en el código y después la moviste, la key sigue en el historial. Hay bots que escanean GitHub en tiempo real buscando exactamente eso.

Rota cualquier key que hayas expuesto. No importa cuánto tiempo haya pasado. Ve al dashboard del servicio (Stripe, OpenAI, Supabase, lo que sea) y genera una key nueva. La vieja queda inválida.

Verifica que tu archivo .env no sea público. Suena obvio, pero es un error que aparece en repos reales más seguido de lo que imaginas.

Para configuración detallada de variables de entorno en Next.js, el paso 3 de la guía de seguridad para Next.js cubre exactamente qué va en .env.local versus NEXT_PUBLIC_.

Paso 2: Revisa tus dependencias

Tu package.json puede verse impecable y tener CVEs activos en node_modules. La IA instala las versiones que conoce de su entrenamiento — ese entrenamiento tiene una fecha de corte. Las vulnerabilidades descubiertas después no las conoce.

# Corre esto en tu proyecto para ver qué tienes
npm audit
 
# Si quieres el reporte más detallado
npm audit --json | head -50

El output te muestra las vulnerabilidades por severidad. Las de severidad critical y high son las que necesitas resolver primero.

Para actualizar paquetes vulnerables:

# Actualiza automáticamente lo que npm puede resolver
npm audit fix
 
# Para actualizaciones que rompen la API (hazlo con cuidado)
npm audit fix --force

El --force puede romper cosas si hay cambios importantes en la API. Testea después de correrlo.

Paso 3: Verifica la autenticación en tus rutas de API

Broken Access Control es el #1 del OWASP Top 10. La IA genera el endpoint que pediste — si no especificaste "verifica quién está haciendo la petición", no lo hace.

El patrón más común que vemos al escanear repos:

// MAL: cualquiera puede llamar este endpoint
export async function GET(req: Request) {
  const users = await db.users.findMany();
  return Response.json(users);
}
 
// BIEN: verifica la sesión antes de devolver datos
export async function GET(req: Request) {
  const { data: { user } } = await supabase.auth.getUser();
  if (!user) {
    return Response.json({ error: "No autorizado" }, { status: 401 });
  }
  const users = await db.users.findMany({ where: { id: user.id } });
  return Response.json(users);
}

Revisa cada endpoint en tu app con esta pregunta: "¿Qué pasa si alguien que no está logueado llama este endpoint directamente?" Si la respuesta es "obtiene datos que no debería ver", tienes un problema de access control.

Paso 4: Configura los security headers

Los security headers son instrucciones que tu servidor manda al navegador para proteger a tus usuarios. La IA raramente los configura porque no son visibles en el comportamiento funcional de la app.

Los más importantes para una app con usuarios:

// En next.config.ts
const securityHeaders = [
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-XSS-Protection", value: "1; mode=block" },
  {
    key: "Strict-Transport-Security",
    value: "max-age=63072000; includeSubDomains; preload"
  },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; script-src 'self' 'unsafe-inline'"
  },
];

Puedes verificar los headers de tu app deployada con el verificador de cabeceras de seguridad gratis.

Paso 5: Automatiza el escaneo

Hacer todo esto manualmente antes de cada deploy no es sostenible. El punto es automatizarlo para que no tengas que pensarlo.

La opción más rápida: conecta tu repo a Data Hogo. El scanner corre el análisis en menos de 5 minutos y cubre los cinco pasos anteriores en paralelo — secretos, dependencias, patrones de código, configuración y headers. Cada finding viene con una explicación en español de qué está mal y cómo arreglarlo.

Escanea tu repo gratis →

La opción más técnica: agrega npm audit y semgrep a tu GitHub Actions workflow. Tienes más control pero más configuración que mantener.

Para la mayoría de developers que usan IA para programar, la opción automatizada gana. El tiempo que ahorras no configurando el pipeline lo usas en el producto.

Paso 6: Mantén el ritmo

La seguridad no es un estado que alcanzas y listo. Cada vez que agregas una dependencia nueva, generates código con IA o haces deploy de una feature nueva, la superficie de ataque cambia.

Un ritmo práctico para proyectos activos:

Antes de cada deploy importante: escaneo completo del repo
Una vez por semana: npm audit para revisar nuevas vulnerabilidades en dependencias
Cada vez que rotas una key: verifica que la vieja no esté en el historial de Git

Si tu app maneja cuentas de usuario, pagos o datos reales, este ritmo no es opcional. Una brecha de seguridad en producción cuesta mucho más — en tiempo, reputación y potencialmente dinero — que 15 minutos de revisión semanal.

Para profundizar en los errores específicos que el código de IA comete, revisa la guía de vulnerabilidades en código generado por IA.

Checklist rápido antes del deploy

Guarda esto:

No hay API keys ni secretos en el código fuente ni en el historial de Git
El archivo .env está en .gitignore y no está en el repo
npm audit no muestra vulnerabilidades críticas o altas
Todos los endpoints de API verifican la sesión del usuario
Los security headers están configurados en producción
Las políticas RLS están activas si usas Supabase

Preguntas frecuentes

¿Qué debo revisar antes de hacer deploy si programo con IA?

Cuatro cosas críticas: primero, que ninguna API key o secreto esté en tu código o historial de Git. Segundo, que tus dependencias no tengan CVEs activos (npm audit). Tercero, que tus rutas de API verifiquen quién hace la petición. Cuarto, que tu app deployada tenga los security headers básicos. Un scanner automatizado como Data Hogo revisa todo esto en menos de 5 minutos.

¿El código generado por Cursor o Claude es seguro?

Puede funcionar perfectamente y tener vulnerabilidades al mismo tiempo. Las herramientas de IA optimizan para código que funciona, no para código seguro. El reporte Veracode 2025 encontró que el 45% del código generado por IA tiene al menos una vulnerabilidad. Agregar un escaneo automático cierra esa brecha.

¿Cuánto tiempo toma asegurar una app hecha con IA?

La revisión inicial toma entre 30 minutos y 2 horas dependiendo del tamaño del proyecto. Una vez que tienes los procesos en su lugar — variables de entorno correctas, escaneo automático en el workflow — el mantenimiento es menos de 15 minutos por semana.

¿Necesito saber de seguridad para usar esta guía?

No. Esta guía está escrita para developers que saben programar pero nunca han estudiado seguridad formalmente. Cada paso viene con ejemplos de código y explicaciones de por qué importa — no asume ningún conocimiento previo de seguridad.

¿Con qué frecuencia debo escanear mi repo?

Idealmente en cada PR importante o al menos una vez por semana en proyectos activos. Si usas herramientas de IA para programar, el ritmo de cambios es más rápido y las vulnerabilidades se introducen igual de rápido. El plan Basic de Data Hogo ($12/mes) cubre 15 scans mensuales — suficiente para escanear antes de cada deploy.