La persistencia de estado en aplicaciones modernas sigue siendo el vector de ataque más explotado. Almacenar tokens de acceso en el localStorage de un cliente es una mala práctica técnica que expone directamente cualquier sesión a ataques XSS (Cross-Site Scripting).
El ecosistema de Next.js y NestJS requiere una arquitectura stateless rígida. La única estrategia segura en producción implica delegar la gestión del refresh token a cookies HttpOnly, Secure y SameSite=Strict, eliminando el acceso del lado del cliente a credenciales críticas.
Para proyectos empresariales complejos, como el desarrollo web con arquitecturas desacopladas, la validación de tokens debe ocurrir antes de que la petición toque el controlador final. Esto exige middleware perimetral y guards estrictos en el backend.
Prevención de vulnerabilidades XSS y CSRF
Un ataque XSS ocurre cuando un script malicioso se ejecuta en el navegador del usuario y roba el JWT si está en localStorage. Si usamos cookies HttpOnly, Javascript no puede leerlas, bloqueando el XSS de raíz.
Sin embargo, las cookies introducen el riesgo de CSRF (Cross-Site Request Forgery). Para mitigarlo, NestJS debe validar el origen exacto de la petición y Next.js debe implementar tokens Anti-CSRF o confiar en los encabezados personalizados (ej. x-csrf-token).
El diseño de un backend seguro exige que las respuestas con credenciales no sean cacheadas. Configura siempre las cabeceras Cache-Control: no-store en los endpoints de autenticación.
Configuración de guards e interceptores en backend
En NestJS, la protección de rutas no se maneja en los controladores, sino en la capa de Guards. Un JwtAuthGuard debe extraer el token de la cabecera Authorization (para el access token de corta duración) o de las cookies (para el refresh token).
Si estás comparando ecosistemas, como en el caso de Express vs NestJS, notarás que NestJS facilita la inyección de dependencias para validar firmas de tokens de forma centralizada y síncrona.
Los interceptores se utilizan para mutar la respuesta. Al iniciar sesión, un interceptor intercepta el JWT generado y lo adhiere a la cabecera Set-Cookie antes de devolver el payload al frontend, automatizando el flujo de seguridad.
Estrategias de rotación de tokens de acceso continuo
Un JWT nunca debe tener un tiempo de vida largo (TTL). El estándar es configurar el access token para que expire en 15 minutos, mientras que el refresh token (alojado en la cookie HttpOnly) dura de 7 a 30 días.
Cuando el access token caduca, Next.js realiza una petición silenciosa al endpoint /refresh de NestJS. El servidor lee la cookie HttpOnly, valida que no haya sido revocada en base de datos, y emite un nuevo access token.
Para un software a medida en Madrid que requiera alta seguridad financiera, implementar listas de revocación (blacklisting) en Redis es obligatorio. Esto bloquea instantáneamente un refresh token si se detecta un inicio de sesión anómalo.
Para escalar esto eficientemente, es crucial entender los tipos de arquitectura backend y cómo interactúan con cachés en memoria para no saturar la base de datos principal en cada validación.
Middleware perimetral para protección de rutas
En Next.js, el middleware (middleware.ts) actúa como el firewall del frontend. En lugar de verificar el estado de autenticación en cada componente de React, el middleware intercepta la petición a nivel de servidor Edge.
Si decides entre React vs Next.js, el middleware perimetral de Next.js es la principal ventaja. Evalúa si la cookie del refresh token existe antes de permitir el enrutamiento a páginas privadas.
Si la cookie está ausente o es inválida, el middleware redirige automáticamente al usuario a /login con un código de estado 307. Esto ahorra procesamiento al cliente y evita parpadeos de interfaz (FOUC) por redirecciones tardías en el navegador.
Esta lógica de middleware no solo aplica a interfaces web; un ecosistema integrado con una aplicación móvil en Madrid puede requerir variaciones similares en la arquitectura backend para normalizar el rechazo temprano de tokens no válidos.
CodeZone Pro Tip: Next.js Edge Middleware para verificación de JWT
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { jwtVerify } from 'jose'; // jsonwebtoken no soporta Edge runtime
export async function middleware(req: NextRequest) {
const token = req.cookies.get('refresh_token')?.value;
if (!token && req.nextUrl.pathname.startsWith('/dashboard')) {
return NextResponse.redirect(new URL('/login', req.url));
}
// Validación de firma directa en el Edge (requiere secreto en variables de entorno)
try {
await jwtVerify(token!, new TextEncoder().encode(process.env.JWT_SECRET));
return NextResponse.next();
} catch (err) {
return NextResponse.redirect(new URL('/login', req.url));
}
}Ignorar las Cookies HttpOnly acumula Deuda Técnica Crítica
Implementar autenticación basada únicamente en localStorage por comodidad o falta de tiempo genera una deuda técnica inmediata. A medida que la aplicación escala, la reescritura de toda la capa de persistencia de sesiones paralizará nuevos desarrollos. Cualquier auditoría de seguridad marcará el sistema como vulnerable a XSS, obligando a refactorizar el flujo de tokens y los guards del backend antes de poder lanzar nuevas características o integrar servicios de terceros.
