Un ataque CSRF tradicional funciona colocando un formulario rellenado previamente en el sitio del atacante y enviándolo de origen cruzado. A continuación, utiliza las credenciales que se envían automáticamente con la solicitud para enviar los datos del atacante bajo la apariencia de la identidad del propietario del navegador.

Al colocar un token tanto en las cookies (o sesión) como en el formulario y verificar si coinciden, puede defenderse de esto. El atacante no puede simplemente enviar una solicitud para obtener el token CSRF porque:

• Si logran que el usuario realice la solicitud, la Política del mismo origen les impide leer la respuesta con el token en ella.
• Si realizan la solicitud directamente, no tendrán las cookies del usuario, por lo que obtendrán un token diferente (que no coincide).

Cuando se trata de un servicio web (y necesita que la API funcione en todos los orígenes), las cosas son diferentes. La defensa clave aquí es diseñar la API para que:

• Las credenciales van a algún lugar donde no se enviarán automáticamente (por ejemplo, en un encabezado de Autorización) para que el atacante no pueda realizar la solicitud con ellas.
• La solicitud está en un formato en el que requiere una solicitud de verificación previa de CORS para enviar (por ejemplo, con un Content-Type: application/json ).

… o ambos.