Vibe Coding y Seguridad: Riesgos Reales y Checklist para Apps Hechas con IA

¿El vibe coding es malo? No, en sí mismo no. Describir lo que querés y dejar que una IA escriba el código es una forma realmente más rápida de construir software. Lo malo es publicar ese código para usuarios reales sin que nadie lo revise, porque las herramientas de IA optimizan para que el código ande, no para que sea seguro. En esta guía vas a ver dónde aparece esa brecha, con ejemplos concretos, y un checklist de seguridad para vibe coding que podés correr antes de lanzar.

El término lo popularizó Andrej Karpathy en febrero de 2025, cuando describió "un nuevo tipo de programación que llamo vibe coding, donde te entregás por completo a las vibras, abrazás lo exponencial y te olvidás de que el código existe". Olvidarse de que el código existe está bien para un proyecto descartable. Es justo el problema cuando ese proyecto guarda datos de clientes.

Lo bueno del vibe coding

Antes de hablar de riesgos, seamos justos. Programar con Cursor, Claude Code, Lovable, Bolt, v0 o Replit tiene ventajas reales:

• Velocidad. Un prototipo funcionando en horas en vez de semanas. Un founder valida una idea antes de contratar un equipo.
• Acceso. Diseñadores, product managers y expertos del negocio pueden armar las herramientas que antes tenían que pedir.
• Menos boilerplate. Un dev con experiencia se saltea el CRUD repetitivo, los formularios y el código pegamento, y se concentra en lo difícil.
• Iteración rápida. Cambiar un flujo es un prompt, no un sprint.

Nada de eso es un problema de seguridad. El problema es lo que se pierde en el camino: el code review, el dev senior que ve una clave en el archivo equivocado, el entorno de staging, el momento en que alguien pregunta "¿quién puede llamar a este endpoint?".

Qué dicen los datos

No es solo anecdótico. Algunos datos que conviene tener presentes:

• El código inseguro es frecuente. El GenAI Code Security Report 2025 de Veracode probó código de más de 100 modelos de lenguaje en tareas de Java, JavaScript, Python y C#, y el 45% de las muestras falló las pruebas de seguridad e introdujo vulnerabilidades del OWASP Top 10.
• Los modelos inventan paquetes. El paper "We Have a Package for You!", presentado en USENIX Security 2025, generó 576.000 muestras de código con 16 modelos y encontró que el 19,7% de los paquetes recomendados no existía. Si un atacante registra uno de esos nombres, ejecuta código en cada máquina que lo instale.
• Hubo apps reales expuestas. El CVE-2025-48757 describió proyectos generados con Lovable con políticas de Row Level Security insuficientes, que permitían a atacantes sin autenticar leer o escribir tablas de la base. El investigador que lo reportó encontró más de 170 apps afectadas.

Los riesgos de seguridad del vibe coding que aparecen una y otra vez

1. Secretos hardcodeados

La IA pone la clave donde el código la necesita. Si eso es un componente de React, la clave viaja al navegador de cada visitante. Si es un archivo de configuración, termina en git, y borrarlo después no lo saca del historial.

// lib/ai.ts (importado desde un client component)
const openai = new OpenAI({ apiKey: "sk-proj-..." });

// next.config.js
env: { NEXT_PUBLIC_STRIPE_SECRET: process.env.STRIPE_SECRET_KEY }

Todo lo que tenga el prefijo NEXT_PUBLIC_ (o VITE_ en Vite) se incluye en el código del cliente. Los secretos van en código que solo corre en el servidor, y cualquier clave que haya pasado por un navegador o un commit hay que rotarla, no alcanza con borrarla. En nuestra comparación de herramientas de detección de secretos te mostramos cómo revisar todo el historial de git, y un secret scanner puede hacerlo en cada push.

2. Endpoints sin autenticación

// app/api/orders/route.ts
export async function GET() {
  const orders = await db.order.findMany();
  return Response.json(orders); // todas las órdenes, para cualquiera
}

El prompt fue "mostrame la página de órdenes". El modelo hizo que funcione. Nadie preguntó quién debería verla.

3. IDOR: el bug que parece correcto

// app/api/invoices/[id]/route.ts
export async function GET(req: Request, { params }) {
  const session = await auth();
  if (!session) return new Response("Unauthorized", { status: 401 });
  const invoice = await db.invoice.findUnique({ where: { id: params.id } });
  return Response.json(invoice); // no verifica que invoice.userId === session.user.id
}

Hay un chequeo de login, así que pasa una revisión rápida. Pero cualquier usuario logueado puede recorrer IDs y leer las facturas de todos. Es una vulnerabilidad IDOR, parte de broken access control, que encabeza el OWASP Top 10. La solución es acotar la query: where: { id: params.id, userId: session.user.id }.

4. Defaults inseguros

Los modelos eligen lo que hace desaparecer el error. Un error de CORS se convierte en Access-Control-Allow-Origin: * con credenciales. Una cookie que falla se convierte en una cookie sin Secure. Un crash se convierte en un stack trace que le llega al cliente. Cada cosa por separado es chica; juntas hacen que cualquier otro bug sea más fácil de explotar.

5. Paquetes alucinados y typosquatting

Cuando el modelo te sugiere un npm install o pip install, fijate que el paquete exista, que sea el que querías y que tenga un mantenedor y un historial reales. Hay atacantes que publican paquetes con los nombres que los modelos suelen inventar (a esto a veces se le dice slopsquatting) y con nombres a una tecla de distancia de los populares. Fijá versiones y commiteá el lockfile.

6. Claves de Supabase expuestas y Row Level Security

Supabase es el backend por defecto de muchísimas apps hechas con vibe coding, y su documentación es clara: una tabla en un schema expuesto sin RLS la puede leer y escribir cualquier rol que tenga permisos sobre ella. Solo la publishable key (o la anon key legacy) está pensada para el navegador, y es segura únicamente porque RLS limita lo que puede alcanzar. Una secret key o service_role se saltea RLS y nunca tiene que salir del servidor.

alter table public.invoices enable row level security;

create policy "owners read their invoices"
  on public.invoices for select
  using ( auth.uid() = user_id );

Las políticas las vemos a fondo en la guía de Supabase RLS.

Cuándo el vibe coding está bien y cuándo es riesgoso

Checklist de seguridad para vibe coding

Corrélo antes de compartir el link, y otra vez antes de empezar a cobrar.

Secretos

• Ninguna API key, token ni contraseña en el código fuente ni en el bundle del cliente.
• Ningún .env en git, y todo el historial escaneado, no solo el último commit.
• Toda clave que alguna vez quedó expuesta, rotada.

Autenticación y autorización

• Cada ruta de API que lee o escribe datos valida la sesión.
• Cada query que trae un registro por ID también filtra por dueño o tenant.
• Las rutas de admin chequean el rol en el servidor, no un flag en el frontend.
• Probalo: logueate como el usuario A, pedí un recurso del usuario B y esperá un 403 o 404.

Base de datos

• Row Level Security activado en todas las tablas de schemas expuestos, con políticas por usuario.
• En el navegador, solo la publishable o anon key; las secret y service_role, solo en el servidor.
• Queries parametrizadas, nunca armadas concatenando strings.

Dependencias

• Cada paquete que agregó la IA existe de verdad y es el que buscabas.
• Lockfile commiteado, CVEs conocidos revisados, paquetes sin uso eliminados.

Configuración

• CORS limitado a tus propios orígenes; cookies con Secure, HttpOnly y SameSite.
• Modo debug apagado y mensajes de error genéricos en producción.
• Rate limiting en login, signup, reset de contraseña y todo lo que cueste plata (llamadas a IA, emails, SMS).
• GitHub Actions con permisos mínimos, contenedores que no corren como root, ningún bucket público por accidente.

Cómo revisar una app hecha con vibe coding

Pedile a la IA una pasada de seguridad, pero no te quedes ahí. Un prompt tipo "revisá esto buscando problemas de seguridad" encuentra algunas cosas, pero el mismo modelo que escribió el código suele compartir sus puntos ciegos. En nuestro análisis de la revisión de seguridad con Claude Code vas a ver qué detecta y qué se le escapa a una revisión hecha por un asistente.

Usá scanners dedicados. Los scanners de secretos, de dependencias y el análisis estático encuentran los problemas mecánicos a bajo costo. Nuestra lista de escáneres de vulnerabilidades open source es un buen punto de partida gratis, y el AI SAST suma razonamiento sobre autorización y flujo de datos, que es donde se esconde el IDOR.

Usá una revisión pensada para código generado con IA. Por ejemplo, con Nurbak conectás GitHub y escaneás un repo. Su propio modelo de IA self-hosted analiza el código (el análisis no manda tu código a OpenAI ni a Anthropic) y reporta vulnerabilidades explotables con archivo y línea, CVEs de dependencias, configuraciones inseguras de GitHub Actions, Docker, Terraform y Kubernetes, y secretos en el historial de git, con un score de 0 a 100 y explicaciones en lenguaje simple. También puede abrir un Pull Request con el fix más un test de regresión de seguridad (el fix usa Claude, solo con tu consentimiento explícito). El escaneo gratis te muestra completos los 3 hallazgos más importantes. Mirá cómo funciona el AI code review de seguridad.

Sumá personas cuando lo que está en juego lo justifica. Las fallas de lógica de negocio y los ataques encadenados todavía necesitan a alguien pensando. Si le vendés a empresas, cobrás o guardás datos sensibles, planificá un pentest antes de un lanzamiento grande. En nuestra guía para elegir una empresa de pentesting te contamos qué pedir, y una auditoría de seguridad del código es una opción más liviana entre pentests.

Conclusión

El vibe coding no es malo; el vibe coding sin revisión, sí. La misma velocidad que te deja lanzar en un fin de semana deja pasar un chequeo de auth que falta, una clave filtrada o un paquete inventado. Tratá al código generado por IA como el de un dev junior rápido y talentoso: útil, muchas veces correcto, y nunca mergeado a producción sin revisión. Corré el checklist, automatizá el escaneo con un AI code review en cada cambio y dejá a las personas para los momentos críticos.

Artículos relacionados

• Supabase RLS: la guía completa
• Qué es una vulnerabilidad IDOR
• Herramientas de detección de secretos
• OWASP Top 10 2025
• Checklist de seguridad de APIs