CSRF es cuando, con solo abrir otro sitio mientras sigues con la sesión iniciada, se dispara una transferencia o un cambio de configuración sin que lo sepas. Aquí tienes cómo funciona y cómo prevenirlo de forma fiable (sin pasos de ataque).
Por qué funciona (el mecanismo)
El navegador adjunta automáticamente las cookies de un sitio a las solicitudes dirigidas a ese sitio. Así que si un usuario tiene la sesión iniciada en su banco, una solicitud al banco disparada desde una página maliciosa sigue llevando "las cookies del usuario". Para el servidor, es indistinguible de una acción legítima.
Donde XSS "ejecuta código en el navegador de la víctima", CSRF "toma prestado el estado con sesión iniciada de la víctima" (→ Qué es XSS).
Defensa
Exige un token CSRF
En las acciones que cambian estado (envíos de formularios, APIs), exige un token de un solo uso, imposible de adivinar, emitido por el servidor; rechaza las solicitudes sin él. La mayoría de frameworks lo traen.
Establece cookies SameSite
Marca las cookies de sesión como SameSite=Lax (o Strict) para que no se adjunten a solicitudes originadas entre sitios. Lax es el valor por defecto moderno y ayuda mucho por sí solo.
No uses GET para cambios de estado
GET (visualizar) no debe tener efectos secundarios. Haz los cambios con POST/PUT/DELETE y pásalos por la validación de token.
Comprueba Origin / Referer
Para acciones sensibles, verifica que el Origin de la solicitud es tu propio sitio y rechaza los orígenes externos.
La opinión de este sitio: en gran parte 'resuelto', pero no te confíes
Los tokens CSRF de los frameworks más el valor por defecto SameSite=Lax del navegador han reducido enormemente el CSRF clásico. Aun así, sigue ocurriendo en APIs propias, configuraciones heredadas y paneles de administración que se saltaron el token. Aunque "lo dejes en manos del framework", verifica una vez por ti mismo que las rutas que cambian estado realmente ejecutan la validación del token.
Huecos comunes
Aunque conozcas el mecanismo, las implementaciones tienden a fallar en dos puntos.
- GET con efectos secundarios: si un GET de visualización cambia estado, una etiqueta de imagen o un enlace normal bastan para el CSRF. Haz los cambios de estado con POST/PUT/DELETE y pásalos por la validación de token.
- Olvidar la validación de token en algunas rutas: las APIs y las funciones de administración añadidas más tarde suelen saltarse el token. No asumas "el framework lo tiene": inventaría una vez cada ruta que cambie estado.
CSRF, XSS y SSRF: diferencias
Estos tres nombres parecidos se distinguen por quién envía la petición y de qué se aprovechan.
| Ataque | Quién envía la petición | De qué se abusa | Defensa principal |
|---|---|---|---|
| CSRF | El navegador del usuario, sin que el usuario lo sepa | Que el navegador adjunte las cookies automáticamente | Tokens CSRF, cookies SameSite |
| XSS | El script del atacante que se ejecuta en el navegador del usuario | La falta de escape al renderizar la página | Escape en la salida, CSP |
| SSRF | Tu servidor | Una función que obtiene una URL que se le indica | Lista de destinos permitidos, bloqueo de direcciones internas |
El CSRF y el XSS actúan ambos a través del navegador del usuario. Pero si una página tiene XSS, un script dentro de ella puede leer el token CSRF, así que las defensas contra el CSRF quedan anuladas. La protección contra el CSRF da por hecho que el XSS ya está resuelto.
Un caso real: una publicación falsificada tratada como propia del usuario
En 2012, se publicó una amenaza de atacar escuelas primarias a través del formulario de opiniones del sitio web de la ciudad de Yokohama (Japón). El dueño del PC del que parecía proceder fue detenido, y más tarde se supo que la detención fue un error. En diciembre de ese año, la policía de Tokio explicó, según la prensa japonesa, que la publicación se había enviado mediante CSRF: se hizo que el navegador de un visitante la enviara después de abrir un enlace publicado en un foro.
De aquí salen dos lecciones.
- Una petición CSRF es idéntica a una del propio usuario: el servidor solo ve la dirección IP y las cookies del usuario. Los registros por sí solos no pueden distinguir si el usuario la envió o si le hicieron enviarla.
- Los formularios sin inicio de sesión también cuentan: ese formulario de opiniones no requería iniciar sesión. Pon un token en cualquier envío que no quieras que otros provoquen (publicaciones, solicitudes, denuncias), requiera o no inicio de sesión.
El CSRF sigue siendo una debilidad común. En el «CWE Top 25» de MITRE (las 25 debilidades de software más peligrosas), publicado en diciembre de 2025, el CSRF (CWE-352) quedó en tercer lugar.
Cómo comprobar tu propio sitio
Establece SameSite de forma explícita en las cookies de sesión
Comprueba el atributo SameSite de la cookie de sesión en las herramientas para desarrolladores del navegador (Aplicación → Cookies) o con la auditoría del sitio. Chrome y Edge tratan como Lax las cookies sin el atributo, pero Safari y Firefox no lo hacen por defecto. No dependas de los valores por defecto del navegador; establece tú mismo SameSite=Lax o Strict.
Revisa las exenciones de CSRF
Comprueba si la protección CSRF del framework está desactivada en algunas rutas (csrf_exempt de Django, la lista de excepciones de Laravel, skip_forgery_protection de Rails, etc.). Donde haya un motivo para desactivarla, como un receptor de webhooks, protege la ruta con verificación de firma en su lugar.
Busca rutas GET que cambien estado
Repasa tu lista de rutas en busca de rutas GET que borren, actualicen o cierren sesión. Pásalas a POST o similar y hazlas pasar por la validación de token.
Añade una comprobación más a las acciones sensibles
Para cambiar la contraseña o el correo, enviar dinero o conceder permisos, pide la contraseña actual o la autenticación multifactor además del token. Aunque se falsifique una petición, la confirmación del usuario la detiene.
Fuentes (primarias)
- OWASP, «Cross-Site Request Forgery Prevention Cheat Sheet» (en inglés) — cheatsheetseries.owasp.org (tokens, Sec-Fetch-Site, límites de SameSite, el XSS anula las defensas contra el CSRF, nada de cambios de estado por GET)
- MITRE, «2025 CWE Top 25 Most Dangerous Software Weaknesses» (diciembre de 2025, en inglés) — cwe.mitre.org (CWE-352 en tercer lugar)
- web.dev, «SameSite cookies explained» (en inglés) — web.dev (qué navegadores tratan como Lax las cookies sin el atributo)
- INTERNET Watch, noticia sobre el caso del malware de control remoto (14 de diciembre de 2012, en japonés) — internet.watch.impress.co.jp (explicación policial de que se usó CSRF para la publicación de Yokohama)
- @IT, artículo sobre las detenciones erróneas causadas por malware de suplantación y CSRF (noviembre de 2012, en japonés) — atmarkit.itmedia.co.jp
- IPA, «How to Secure Your Web Site» — ipa.go.jp (en japonés)
Sigue leyendo
- Glosario: Qué es XSS · Qué es SSRF
- Fundamentos: Fundamentos de seguridad