Seguridad en Next.js: lo que omiten los tutoriales de YouTube

Next.js es el default para startups y agencias en Puerto Rico construyendo sitios modernos. Los tutoriales muestran autenticación en quince minutos; rara vez mencionan CSRF en server actions, exposición de variables NEXT_PUBLIC_, o rate limiting en route handlers. OWASP ASVS debería ser bookmark obligatorio para cualquier lead dev.

Empecemos por headers: Content-Security-Policy estricta (con

Empecemos por headers: Content-Security-Policy estricta (con nonce para scripts inline legítimos), X-Frame-Options o frame-ancestors, Referrer-Policy, y Permissions-Policy. Next.js permite configurarlos en next.config — no es opcional si maneja datos de clientes. CSS-Tricks ha publicado buenos ejemplos de CSP con frameworks modernos; adáptelos, no copie políticas genéricas.

Server Components reducen JS en cliente pero no eliminan riesgo server-side

Server Components reducen JS en cliente pero no eliminan riesgo server-side. Valide toda entrada con Zod o similar en el borde del servidor; nunca confíe en validación solo en cliente. Para API routes que mutan estado, use tokens anti-CSRF o verifique Origin/Referer consistentemente. Autenticación con better-auth, NextAuth o Clerk debe centralizarse — patrones ad hoc por ruta acumulan deuda.

Secretos: rote keys de API, use variables de entorno solo en server, audite que ningún service role key termine en bundle cliente. En despliegues AWS con OpenNext o contenedores, IAM roles por tarea — no access keys en .env en la imagen.

Dependency hygiene: npm audit y Dependabot son baseline; para producción real añada revisión de licencias y pinning en lockfile. Un supply chain compromise en un paquete de iconos puede tumbar su landing de Black Friday.

Next.js seguro no es más lento de construir; es más lento solo si corrige después del pentest. Involucre revisión de seguridad en PRs críticos desde el sprint uno.