CSRF: cookies SameSite y tokens
Comprenda cómo Cross-Site Request Forgery explota las cookies, use SameSite=Strict/Lax para evitarlo y añada tokens de sincronización como protección adicional.
CSRF: cookies SameSite y tokens es una lección gratuita de Frontend Academy en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Frontend Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Frontend Academy incluye 4 lecciones en total.
¿Qué es CSRF?
Cross-Site Request Forgery: un atacante engaña al navegador de un usuario autenticado para que envíe una solicitud a su sitio. El navegador adjunta las cookies del usuario y el servidor cree que se trata de una solicitud legítima del usuario.
Ataque CSRF clásico
El usuario ha iniciado sesión en bank.com. Visita evil.com. evil.com envía un formulario oculto a bank.com/transfer con el número de cuenta del atacante. El navegador envía automáticamente la cookie de sesión de bank.com. El servidor transfiere el dinero.
El problema de la confianza
CSRF funciona porque los navegadores incluyen automáticamente las cookies en las solicitudes de origen cruzado. Sin protección adicional, el servidor no puede saber que la solicitud proviene de un sitio malicioso.
Cookies SameSite: la solución moderna
El atributo de cookie SameSite controla cuándo se envían las cookies en solicitudes de origen cruzado. Strict: nunca se envían entre orígenes. Lax (valor predeterminado en Chrome): solo se envían en navegaciones GET de nivel superior. None: siempre se envían (también debe especificarse Secure).
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=LaxValor predeterminado SameSite=Lax
Chrome establece todas las cookies como Lax de forma predeterminada si no se especifica SameSite. Esto bloquea la mayoría de los ataques CSRF, pero conviene especificarlo de todos modos.
SameSite=Strict para máxima seguridad
Use Strict para las cookies más sensibles (sesiones de administración y transacciones bancarias). La desventaja es que el usuario parece haber cerrado sesión al llegar mediante un enlace desde otro sitio.
Tokens CSRF (patrón de sincronización)
Para admitir navegadores antiguos o añadir una capa de seguridad, use tokens CSRF. El servidor genera un token aleatorio, lo inserta en la página y lo exige en cada solicitud que cambie el estado.
// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">
// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
method: 'POST',
headers: { 'X-CSRF-Token': token },
body: JSON.stringify({ amount: 100 })
});
// Server verifies the X-CSRF-Token header matches the user's sessionCookie de doble envío
El servidor establece una cookie CSRF (sin HttpOnly para que JavaScript pueda leerla). El cliente la lee y envía su valor en un encabezado. El servidor comprueba que la cookie coincide con el encabezado. Un atacante no puede leer la cookie entre orígenes, por lo que no puede replicar el encabezado.
Por qué funciona
evil.com, el sitio del atacante, no puede leer las cookies de bank.com (por la política del mismo origen). Por eso no puede establecer el encabezado X-CSRF-Token. La solicitud no supera la comprobación del token en el servidor.
CSRF en SPA con tokens Bearer
Si se autentica mediante Authorization: Bearer <jwt> almacenado en memoria (no en una cookie), CSRF no se aplica: los navegadores no envían encabezados automáticamente. La contrapartida es una mayor vulnerabilidad ante XSS, ya que los tokens accesibles para JavaScript pueden ser robados.
El truco del encabezado personalizado
En las API que solo aceptan JSON con un encabezado personalizado (por ejemplo, X-Requested-With), los navegadores envían una solicitud OPTIONS de comprobación previa y no incluyen cookies en ella. Esto bloquea eficazmente los ataques CSRF basados en formularios simples.
Endpoints idempotentes frente a mutaciones
CSRF afecta principalmente a las solicitudes que cambian el estado (POST, PUT, DELETE). Los endpoints GET deben ser idempotentes, es decir, no producir efectos secundarios, para que un GET falsificado no pueda causar daños.
Comprobación rápida
¿Qué valor de la cookie SameSite impide que las cookies se envíen en la mayoría de las solicitudes entre sitios de forma predeterminada en los navegadores modernos?
Resumen: prevención de CSRF
Establezca SameSite=Lax (o Strict) en las cookies de sesión para bloquear la mayoría de los ataques CSRF. Añada HttpOnly y Secure. Use tokens CSRF (mediante el patrón de sincronización o cookies de doble envío) para obtener protección adicional. Los tokens Bearer en encabezados evitan CSRF, pero aumentan el riesgo de XSS. El truco del encabezado personalizado obliga a realizar una comprobación previa. Haga que las solicitudes GET sean idempotentes.
Preguntas frecuentes
¿La lección «CSRF: cookies SameSite y tokens» es gratis?
Sí — el texto completo de «CSRF: cookies SameSite y tokens» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Frontend Academy, actualiza a CoddyKit PRO. El curso de Frontend Academy incluye 4 lecciones en total.
¿Qué aprenderé en «CSRF: cookies SameSite y tokens»?
Comprenda cómo Cross-Site Request Forgery explota las cookies, use SameSite=Strict/Lax para evitarlo y añada tokens de sincronización como protección adicional. Practicas Frontend Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Frontend Academy?
No se requiere experiencia previa. Frontend Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.
¿Cuánto tiempo toma la lección «CSRF: cookies SameSite y tokens»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Frontend Academy?
Sí. Cada lección de Frontend Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Prevención de XSS: codificación de salida y CSP
- CSRF: cookies SameSite y tokens
- Content Security Policy: nonce y hash
- Flujos de OAuth desde el frontend