// guía de seguridad
Seguridad para apps hechas con v0 (Vercel)
v0 de Vercel genera apps Next.js + shadcn/ui. Next.js tiene buenas defaults de seguridad (server components, automatic XSS escaping), pero también patrones específicos que pueden romper la seguridad si no los entendés: NEXT_PUBLIC_ prefix, Server Actions sin auth, API routes públicas por default.
// contexto del stack
Contexto de v0 (Vercel)
En Next.js, las variables con prefijo `NEXT_PUBLIC_` se exponen al cliente. Server Actions son funciones server-side llamadas desde cliente sin endpoint explícito, lo que puede confundir sobre dónde aplicar auth. No es un error marginal: Escape.tech reportó más de 2.000 vulnerabilidades y 400+ secretos expuestos al analizar 5.600 apps vibe-coded, y un `NEXT_PUBLIC_` mal puesto es justo la clase de fuga que infla ese número.
// hallazgos frecuentes
Vulnerabilidades más comunes en v0 (Vercel)
01 Claves secretas con prefijo NEXT_PUBLIC_
Si una clave tiene `NEXT_PUBLIC_` viaja al bundle. v0 a veces sugiere este prefijo "para que el frontend pueda usarla", lo que es peligroso si la clave es secreta.
→ cómo arreglarlo
Solo poné `NEXT_PUBLIC_` en variables que SÍ pueden ser públicas (Stripe publishable key, Supabase anon key, Google Maps public key). Para secretas, omitir el prefijo y usar solo en Server Components o API routes.
02 Server Actions sin verificación de sesión
Server Actions parecen "automáticamente seguras" porque corren server-side. En realidad, cualquier cliente puede invocarlas con el payload que quiera. Sin auth check explícito, son endpoints públicos.
→ cómo arreglarlo
En cada Server Action, primero verificá la sesión: `const session = await auth(); if (!session) throw new Error("unauthorized");`. Después validá inputs con Zod.
03 API routes públicas por default
Las rutas en `app/api/*` o `pages/api/*` son públicas hasta que les agregás auth. v0 genera muchas rutas para prototipar y los guards quedan pendientes.
→ cómo arreglarlo
Implementá un middleware en `middleware.ts` que requiera sesión para `/api/*` excepto rutas explícitamente públicas. O agregá el check en cada route handler.
04 Headers de seguridad sin configurar en vercel.json
Vercel no agrega CSP, HSTS, X-Frame-Options por default. La opción más común es configurarlos en `vercel.json` o en `next.config.js`.
→ cómo arreglarlo
Agregá `headers()` en `next.config.js` o `headers` en `vercel.json`. Plantilla en nuestro post de security headers.
05 shadcn/ui con componentes que usan dangerouslySetInnerHTML
Algunos componentes de shadcn/ui o snippets generados por v0 usan `dangerouslySetInnerHTML` para renderizar contenido. Si ese contenido viene de input de usuario, abre XSS.
→ cómo arreglarlo
Evitá `dangerouslySetInnerHTML` para contenido user-provided. Si necesitás renderizar markdown, usá una librería como `react-markdown` con `rehype-sanitize`. Si necesitás HTML rico, sanitizalo con DOMPurify en server.
// checklist pre-launch
Checklist pre-launch para v0 (Vercel)
- Auditar variables NEXT_PUBLIC_: confirmar que cada una es realmente pública
- Cada Server Action verifica sesión antes de procesar
- API routes tienen middleware o checks de auth
- Configurar security headers en vercel.json o next.config.js
- Inputs validados con Zod (server-side)
- Evitar dangerouslySetInnerHTML con contenido de usuario
- Si usás Supabase: habilitar RLS
- Stripear console.log en producción (next.config.js: compiler.removeConsole)
- Auditar con VibeAuditt antes del launch
// lectura relacionada
Posts relacionados
// escaneá ahora
Audita tu app v0 (Vercel) gratis
VibeAuditt detecta automáticamente los errores de este checklist en menos de un minuto. Sin tarjeta, sin instalación.