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.

Headers de seguridad en next.config

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. 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.

Manejo de secretos y llaves de API

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.

Seguridad sin frenar el desarrollo

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.