Saltar al contenido
The Visual Layer

Mostrando: HttpOnly, el riesgo de CSRF y cómo protegerte con un token anti‑CSRF

Seguridad en Aplicaciones Web

HttpOnly, el riesgo de CSRF y cómo protegerte con un token anti‑CSRF

La infografía explica por qué HttpOnly no impide los ataques CSRF y muestra un flujo seguro con token anti‑CSRF, ejemplos en Angular y Node.js/Express, buenas prácticas y configuración recomendada de cookies.

HttpOnly mitiga XSS, pero no CSRF; añade y valida un token anti‑CSRF en cada petición que cambie estado.

Complejidad
Intermedia
Lectura
5 min de lectura
Publicada

Con la imagen ajustada, las flechas izquierda y derecha van a la infografía anterior y siguiente. Al acercarla, las flechas la desplazan. Las teclas más y menos acercan y alejan, y la tecla cero vuelve a ajustarla.

Cargando la imagen…

Infografía en español titulada “HttpOnly, el riesgo de CSRF y cómo protegerte”. Explica que HttpOnly no evita CSRF y propone usar un token anti‑CSRF validado por el servidor. Muestra el flujo de autenticación y validación del token, ejemplos de código en Angular y Node.js/Express, una lista de buenas prácticas y una tabla con configuración recomendada de cookies (HttpOnly, Secure, SameSite).

Sobre esta infografía

Resumen editorial: La pieza define CSRF como la ejecución forzada de acciones en una aplicación por parte del navegador autenticado del usuario, inducido desde un sitio malicioso. Aclara que la cookie de sesión HttpOnly impide que JavaScript lea el token (mitiga XSS), pero no evita que el navegador envíe automáticamente esa cookie, por lo que no protege de CSRF. Concluye que se necesita un token anti‑CSRF adicional que el servidor emita y valide en cada petición que cambie estado (POST, PUT, PATCH, DELETE). Se describe un flujo seguro: el usuario inicia sesión; el servidor responde con cookie de sesión (HttpOnly, Secure, SameSite) y un token anti‑CSRF. El frontend guarda el token (por ejemplo, en memoria) y lo envía en un encabezado dedicado en cada petición sensible. El backend valida que el token coincida con el esperado y que la sesión sea válida antes de ejecutar la acción. Incluye ejemplos de implementación: en Angular, un servicio guarda el token y un HttpInterceptor lo adjunta solo en métodos que modifican estado. En Node.js/Express, se muestra cómo generar y devolver el token en el login y un middleware que valida el encabezado en rutas sensibles. La pieza remata con buenas prácticas (SameSite, no guardar el token anti‑CSRF en cookies, nunca desactivar CORS, validar Origin/Referer, usar HTTPS, combinar con CSP y validación de entradas) y una tabla de configuración recomendada de cookies (HttpOnly, Secure, SameSite Lax/Strict, path mínimo, dominio exacto, expiración corta).

Ideas clave

  • HttpOnly evita que JavaScript lea la cookie, pero no impide el envío automático de la sesión; por sí solo no protege de CSRF.
  • Para peticiones que cambian estado, el servidor debe emitir y validar un token anti‑CSRF único y aleatorio.
  • Adjunta el token en un encabezado específico y no lo almacenes en cookies.
  • Configura las cookies con HttpOnly, Secure, SameSite (Lax o Strict), ruta y dominio mínimos, y expiración corta.
  • Combina la defensa anti‑CSRF con HTTPS, validación de Origin/Referer, CORS correcto, CSP y validación de entradas.
  • El ejemplo muestra cómo implementarlo con un HttpInterceptor en Angular y middleware en Express.

Etiquetas

  • seguridad web
  • csrf
  • httponly
  • cookies
  • samesite
  • xss
  • angular
  • node.js
  • express
  • tokens
  • interceptor http
  • middleware de seguridad

Relacionadas