¿Qué es un ataque CSRF y cómo evitarlo?

Un ataque CSRF (Cross-Site Request Forgery o falsificación de petición en sitios cruzados) consigue que el navegador de un usuario autenticado ejecute una acción que él no ha pedido: una transferencia, un cambio de correo, un alta de administrador. El atacante nunca ve la sesión ni la respuesta del servidor. Actúa a ciegas, aprovechando que el navegador envía las cookies de forma automática.

Puntos clave

• El CSRF no roba la sesión. Eso es session hijacking, otro ataque. En un CSRF el atacante nunca lee la cookie ni la respuesta: solo consigue que se ejecute una acción.
• Es un defecto del servidor, no un descuido del usuario. No se corrige navegando con cuidado ni con un antivirus: se corrige en el código de la aplicación.
• Las defensas reales son cuatro: token antiCSRF, atributo SameSite en las cookies, validación de las cabeceras de origen y no usar GET para acciones que cambian estado.
• El navegador ya te cubre en parte, pero no del todo. Los navegadores Chromium aplican SameSite=Lax por defecto desde 2020; Firefox y Safari usan mecanismos distintos. Nunca confíes en el valor por defecto: decláralo.
• Sigue vivo en 2026 en APIs mal configuradas, endpoints que aceptan JSON sin validar el tipo de contenido, cookies con SameSite=None y aplicaciones heredadas.

Qué es un ataque CSRF

Cross-Site Request Forgery es una vulnerabilidad web que permite a un atacante inducir a un usuario autenticado a ejecutar, sin saberlo, una acción en una aplicación en la que tiene la sesión abierta. Está catalogada como CWE-352 y, aunque tuvo categoría propia en el OWASP Top 10 hasta 2017, hoy se clasifica dentro de los fallos de control de acceso.

La analogía que mejor funciona es la del cheque firmado. Imagina que has firmado un cheque en blanco y lo llevas en el bolsillo. El atacante no puede robártelo ni ver lo que pone. Lo que sí puede es engañarte para que rellenes un importe y un destinatario que él ha elegido, y lo entregues tú mismo. La firma es válida, el banco la acepta, y el atacante nunca ha tocado el cheque.

En términos técnicos, la firma es tu cookie de sesión. El navegador la adjunta automáticamente a cualquier petición dirigida a ese dominio, venga de donde venga. Si la aplicación no comprueba de dónde procede realmente esa petición, la ejecutará como si la hubieras hecho tú.

Aclaración importante: el atacante trabaja a ciegas. La política del mismo origen que aplican los navegadores le impide leer la respuesta del servidor. Puede provocar una acción, no obtener información. Esa es la diferencia esencial entre un CSRF y un ataque que sí compromete la sesión.

Cómo funciona un ataque CSRF, paso a paso

1. La víctima tiene una sesión abierta en la aplicación objetivo: el banco, el ERP, el panel de administración del CMS. Basta con no haber cerrado sesión.
2. El atacante prepara la petición maliciosa. Analiza cómo funciona la aplicación —qué parámetros usa el formulario de transferencia, por ejemplo— y construye una página que reproduce esa petición.
3. La víctima visita la página del atacante. Puede llegar por correo, por mensajería o desde un anuncio malicioso en una web legítima.
4. El navegador ejecuta la petición con las cookies de la víctima. El servidor la recibe correctamente autenticada y la procesa.

Conviene desmontar un mito habitual: no siempre hace falta que la víctima haga clic. Un formulario puede autoenviarse con JavaScript en cuanto la página carga, y una petición GET puede dispararse con una simple etiqueta de imagen invisible de un píxel.

Ejemplo concreto: de una imagen invisible a una transferencia

Supón una aplicación que ejecuta transferencias con una petición GET del tipo /transferencia?destino=12345&importe=1000. El atacante solo necesita incrustar en cualquier página, o incluso en un correo en formato HTML, una imagen apuntando a esa dirección con sus propios valores.

El navegador de la víctima intentará cargar la «imagen», enviará la petición con la cookie de sesión adjunta y el servidor ejecutará la transferencia. La víctima verá un icono de imagen rota. Nada más.

Con peticiones POST el ataque es algo más elaborado —requiere un formulario oculto que se autoenvía— pero el resultado es idéntico. Que la aplicación use POST no la protege por sí solo.

Qué puede conseguir un atacante con un CSRF

El impacto depende por completo de qué acciones permita la aplicación. Los escenarios que más daño causan en un entorno corporativo:

• Cambio de la dirección de correo o de la contraseña. Es la vía preferida: quien controla el correo de recuperación controla la cuenta. Un CSRF que cambia un correo se convierte en robo de cuenta completo.
• Alta de un usuario con privilegios de administrador. Un solo clic de un administrador legítimo puede dejar una puerta abierta permanente.
• Modificación de los datos bancarios de un proveedor en el ERP o en el portal de compras. El fraude se materializa semanas después, en el siguiente pago.
• Cambios de configuración de seguridad: desactivar avisos, registrar un dispositivo nuevo en el segundo factor, alterar reglas de un router o firewall accesible por web.
• Login CSRF: forzar que la víctima inicie sesión en la cuenta del atacante, de modo que la actividad posterior —tarjetas guardadas, documentos subidos— quede en un perfil que él controla.

La lectura de negocio: el CSRF no roba datos por sí mismo, cambia estado. Y en muchas aplicaciones cambiar estado es más grave que leer.

CSRF, XSS y SSRF: tres siglas que no son lo mismo

Un detalle que suele pasarse por alto: si tu aplicación es vulnerable a XSS, tus defensas antiCSRF dejan de servir. El código inyectado se ejecuta dentro del origen de confianza y puede leer el token igual que lo hace la propia aplicación. Corregir el XSS es prioritario también por este motivo.

El SSRF, pese al parecido de las siglas, es un problema distinto: lo tratamos en el artículo sobre vulnerabilidades en APIs y cómo mitigarlas.

Cómo prevenir un ataque CSRF

Todas las defensas efectivas se implementan en el servidor. Ninguna depende de lo que haga el usuario.

Token antiCSRF

Es la defensa de referencia. La aplicación genera un valor aleatorio, impredecible y ligado a la sesión, lo incluye en cada formulario o cabecera de petición y lo valida en el servidor antes de ejecutar la acción.

Por qué funciona: el atacante puede provocar la petición, pero no puede leer el token, porque la política del mismo origen le impide acceder al contenido de una página de otro dominio.

Errores habituales al implementarlo:

• Incluir el token en la URL. Acaba en los registros del proxy, en los del CDN, en el historial del navegador y en la cabecera Referer de la siguiente petición saliente.
• Validarlo solo en algunas rutas y olvidar las de la API.
• Desactivar la protección del framework «temporalmente» para que funcione una integración, y no volver a activarla.

La buena noticia: Django, Laravel, Spring Security, ASP.NET Core y Rails traen esta protección incorporada y activada por defecto. La mala: se desactiva con una línea, y esa línea suele aparecer en las rutas de API.

Atributo SameSite en las cookies (y por qué no basta)

SameSite es un atributo de las cookies que indica al navegador cuándo debe enviarlas en peticiones que vienen de otro sitio. Tiene tres valores: Strict (nunca en peticiones de origen cruzado), Lax (solo en navegaciones de nivel superior mediante GET) y None (siempre, y exige conexión segura).

Desde 2020, los navegadores basados en Chromium tratan como Lax las cookies que no declaran el atributo, un comportamiento ya estándar en ese ecosistema. Firefox no aplica ese valor por defecto y recurre a su protección total de cookies; Safari bloquea la mayoría de cookies de terceros mediante su prevención de rastreo.

Tres consecuencias prácticas:

1. Declara el atributo explícitamente. Es la recomendación de OWASP, precisamente porque el comportamiento por defecto varía entre navegadores. Usa Lax como mínimo y Strict en paneles de administración sin enlaces entrantes.
2. Lax no protege las acciones por GET. Permite la navegación de nivel superior mediante GET, así que si tu aplicación borra, transfiere o modifica algo con una petición GET, sigues expuesto.
3. SameSite=None te deja donde estabas. Si lo necesitas por una integración con terceros, el token antiCSRF pasa a ser obligatorio.

Validación de Origin, Referer y cabeceras Fetch Metadata

El servidor puede comprobar de dónde dice venir la petición. La cabecera Origin es la más fiable en peticiones que cambian estado; Referer sirve como respaldo.

Más moderno y más limpio: las cabeceras Fetch Metadata. Un endpoint que solo acepte peticiones con Sec-Fetch-Site: same-origin rechaza cualquier intento de origen cruzado antes de llegar a la lógica de la aplicación. Chrome, Edge y Firefox las envían, y Safari las incorporó en su versión 16.4, de marzo de 2023.

Regla de implementación: si la cabecera falta, no la des por válida. Rechaza o exige token.

No uses GET para cambiar estado

Parece obvio y sigue apareciendo en auditorías. Las peticiones GET deben ser idempotentes: consultar, nunca modificar. Cualquier acción que altere datos debe ir por POST, PUT, PATCH o DELETE. Esta única regla cierra el vector más fácil de explotar y es condición necesaria para que SameSite=Lax sirva de algo.

Reautenticación en operaciones críticas

Para las acciones de mayor impacto —cambio de contraseña, cambio de correo, transferencias, alta de administradores— exige volver a autenticarse o confirmar con un segundo factor. Es la última línea de defensa: aunque todo lo anterior falle, el atacante no puede aportar algo que no tiene. Va en la misma dirección que una política de accesos y contraseñas bien planteada.

¿Sigue siendo un riesgo el CSRF en 2026?

Menos que hace una década, pero sí. El valor Lax por defecto en Chromium y la protección integrada en los frameworks se llevaron por delante los casos fáciles. Lo que queda es más específico y, por eso mismo, más fácil de pasar por alto:

• Acciones que cambian estado por GET. El vector clásico, que ninguna configuración por defecto cubre.
• Cookies con SameSite=None, habituales en integraciones con pasarelas de pago, widgets embebidos y portales federados.
• Endpoints de API que aceptan varios tipos de contenido. Si tu API procesa un cuerpo enviado como text/plain o como formulario y lo interpreta como JSON, un formulario HTML puede alcanzarla sin activar las comprobaciones previas de CORS.
• Aplicaciones heredadas y dispositivos con interfaz web —routers, cámaras, NAS, impresoras multifunción— donde la protección sencillamente no existe.
• Navegadores antiguos o entornos controlados que no aplican los valores por defecto actuales.

Sobre el WAF, la respuesta es la misma que en otros ataques de lógica: ayuda poco. Puede aplicar reglas sobre Origin y Referer, pero la petición que llega es formalmente correcta y solo la aplicación sabe si esa acción estaba realmente autorizada.

CSRF en APIs y aplicaciones de página única

En una aplicación moderna con front-end desacoplado, el riesgo depende de cómo se transporte la autenticación:

• Si usas cookies para autenticar la API, tienes exposición a CSRF y necesitas las defensas descritas.
• Si usas un token en la cabecera Authorization, el navegador no lo adjunta automáticamente, así que el CSRF clásico no aplica. A cambio, aparecen otros problemas: dónde se almacena ese token y qué ocurre si hay un XSS.

Dos comprobaciones concretas para tu API:

1. Rechaza los tipos de contenido que no esperas. Si tu API solo trabaja con application/json, no aceptes application/x-www-form-urlencoded ni text/plain. Los formularios HTML solo pueden enviar esos tipos, así que rechazarlos elimina la vía.
2. Revisa la configuración de CORS. Una política permisiva combinada con credenciales habilitadas anula buena parte de las protecciones.

Cómo saber si tu aplicación es vulnerable

Qué revisar en el código:

• ¿Hay alguna ruta que modifique datos mediante GET?
• ¿La protección antiCSRF del framework está activa en todas las rutas, incluidas las de API?
• ¿Las cookies de sesión declaran SameSite de forma explícita, junto con Secure y HttpOnly?
• ¿Se valida Origin en las operaciones sensibles?
• ¿Las acciones críticas exigen reautenticación?

Qué encuentran las herramientas y qué no. Un escáner automático detecta la ausencia de token en formularios y las cookies mal configuradas. Lo que no puede valorar es si una acción concreta es lo bastante sensible como para exigir reautenticación, ni encadenar un CSRF con otro fallo menor. Eso aparece en una prueba de intrusión sobre la aplicación, donde alguien razona sobre la lógica de negocio y no solo sobre patrones.

Si no tienes visibilidad de qué aplicaciones y paneles de tu organización están publicados en internet, el punto de partida es otro: el informe de cibervigilancia de Cylum revisa tu exposición externa y te dice qué ve un atacante antes de empezar.

Preguntas frecuentes sobre CSRF

¿Qué diferencia hay entre CSRF y XSS? En un CSRF el atacante fuerza una acción desde otro sitio y no puede leer la respuesta: actúa a ciegas. En un XSS inyecta código que se ejecuta dentro del origen de confianza, con acceso a la sesión y a los datos. Un XSS anula las defensas antiCSRF, porque puede leer el token.

¿Las cookies SameSite resuelven el problema del CSRF? Lo reducen mucho, pero no lo eliminan. El valor Lax permite navegaciones de nivel superior por GET, así que las acciones que cambian estado mediante GET siguen siendo explotables. Además, Firefox y Safari no aplican el mismo comportamiento por defecto que Chromium, y SameSite=None deja la puerta abierta.

¿Qué es un token CSRF? Es un valor aleatorio e impredecible que la aplicación genera, incluye en cada formulario o cabecera y valida en el servidor antes de ejecutar la acción. Funciona porque el atacante puede provocar la petición pero no leer el token: la política del mismo origen se lo impide.

¿Un antivirus protege de un ataque CSRF? No. En un CSRF no interviene ningún malware ni se instala nada en el equipo de la víctima: se abusa de una sesión legítima mediante peticiones web normales. La corrección corresponde a quien desarrolla y mantiene la aplicación, no al usuario final.

¿Las APIs REST son vulnerables a CSRF? Depende de cómo autentiquen. Si usan cookies, sí. Si usan un token en la cabecera Authorization, el navegador no lo adjunta solo y el CSRF clásico no aplica. Riesgo frecuente: aceptar tipos de contenido de formulario en endpoints pensados para JSON.

¿Cómo compruebo si mi web es vulnerable? Revisa si existen acciones que modifiquen datos por GET, si la protección del framework está activa en todas las rutas, si las cookies declaran SameSite explícitamente y si se valida el origen. Un escáner detecta la configuración; la lógica de negocio requiere una prueba manual.

Fuentes

• OWASP Foundation, Cross Site Request Forgery (CSRF) y CSRF Prevention Cheat Sheet. https://owasp.org/www-community/attacks/csrf
• OWASP Foundation, SameSite (comportamiento por defecto del atributo en cada navegador y recomendación de declararlo explícitamente). https://owasp.org/www-community/SameSite
• MITRE, CWE-352: Cross-Site Request Forgery (CSRF). https://cwe.mitre.org/data/definitions/352.html
• PortSwigger Web Security Academy, Bypassing SameSite cookie restrictions. https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions
• Comportamiento de SameSite por defecto en navegadores Chromium desde Chrome 80 (febrero de 2020) y mecanismos alternativos de Firefox y Safari. [VERIFICAR estado en la fecha de publicación]