CSRF (Cross-Site Request Forgery) lleva más de 20 años en el OWASP Top 10 y sigue apareciendo en auditorías de webs con paneles de cliente, zonas de administración o cualquier formulario que ejecute una acción sin pedir confirmación adicional. No roba datos directamente como el XSS: hace que la víctima ejecute una acción sin darse cuenta.
¿Qué es CSRF exactamente?
CSRF explota un hecho simple: el navegador envía automáticamente las cookies de sesión de un dominio en cada petición a ese dominio, sin importar desde qué página se origine la petición. Si tu web confía solo en la cookie de sesión para saber quién hace una acción, un atacante puede fabricar una petición desde una web totalmente distinta y el navegador de la víctima la enviará con su sesión válida incluida.
El ejemplo clásico: cambiar el email de una cuenta
Imagina un panel de cliente con este endpoint, sin ninguna protección adicional:
// cambiar-email.php — solo comprueba la sesión if (isset($_SESSION['user_id'])) { $nuevo_email = $_POST['email']; // actualiza el email sin más comprobación... }
El atacante monta una página en su propio dominio con un formulario invisible que apunta a ese endpoint:
<form action="https://tuweb.com/cambiar-email.php" method="POST" id="f">
<input type="hidden" name="email" value="atacante@correo-malo.com">
</form>
<script>document.getElementById('f').submit()</script>
Si una víctima con sesión abierta en tu web visita esa página del atacante (por un enlace en un email, un anuncio, cualquier sitio), su navegador envía el formulario junto con la cookie de sesión válida de tu web. El servidor lo procesa como una petición legítima porque la sesión es real — solo que quien la originó no fue la víctima, fue el atacante. A partir de ahí, el atacante pide "olvidé mi contraseña" y la recibe en su propio correo.
Por qué un formulario de contacto también es un vector
No hace falta un panel de administración para tener un problema de CSRF. Cualquier acción que cambie estado — enviar un formulario de contacto, dar de alta una suscripción, votar, añadir un comentario — puede usarse para:
- →Saturar tu buzón o tu CRM con envíos masivos automatizados desde webs de terceros (spam a través de tu propio formulario).
- →Falsificar el origen de una solicitud para que parezca que un cliente concreto pidió algo que nunca pidió.
- →Combinarlo con otras técnicas para forzar acciones en cuentas de clientes logueados (cambiar dirección de envío, añadir un producto al carrito, modificar preferencias).
Cómo se protege correctamente (y por qué casi nadie lo hace bien del todo)
1. Token CSRF por formulario y por sesión
La defensa estándar es generar un token aleatorio único por sesión, incluirlo como campo oculto en cada formulario, y rechazar cualquier envío cuyo token no coincida con el de la sesión del servidor. Suena simple, y la parte de "generar el token" lo es. Donde se rompe en la práctica: hay que aplicarlo a todos los endpoints que cambian estado, no solo al formulario de login o al de contacto — panel de cliente, checkout, cambio de datos, cada acción con botón "guardar" o "enviar". Basta que uno se quede sin protección para que el resto no sirva de nada.
2. Cookies SameSite
Marcar la cookie de sesión como SameSite=Lax o SameSite=Strict le dice al navegador que no la envíe en peticiones originadas desde otro dominio. Es una defensa complementaria al token, no un sustituto — algunos flujos legítimos (pagos redirigidos desde una pasarela externa, por ejemplo) se rompen si se configura mal, así que el valor correcto depende de cómo esté montado el resto del sitio.
3. Reautenticación en acciones críticas
Para acciones de alto impacto (cambiar contraseña, email de recuperación, datos de pago), pedir de nuevo la contraseña actual o un código de verificación añade una capa que el token por sí solo no cubre — aunque la sesión ya esté activa.
4. No uses GET para acciones que cambian estado
Si una acción que borra, modifica o crea algo se puede disparar con una simple petición GET (un enlace, incluso una imagen), el ataque ni siquiera necesita un formulario. Toda acción que cambie estado debe ir por POST — y aun así, sin el token del punto 1, sigue expuesta.
El patrón habitual que vemos en auditorías no es "cero protección" — es protección parcial: el login tiene token CSRF pero el formulario de "cambiar dirección de envío" no, o las cookies están mal configuradas para un caso concreto del sitio. Encontrar esos huecos requiere revisar endpoint por endpoint, no aplicar una regla general.
¿Tus formularios y panel de cliente están protegidos contra CSRF?
Auditamos cada acción que cambia estado en tu web — formularios, panel de cliente, checkout — y verificamos si un atacante puede ejecutarlas sin que el usuario lo sepa.
Ver auditoría web →