Una solución rápida contra CSRF es verificar el encabezado HTTP Referer y / o Origin . Al menos uno de estos debe configurarse y el dominio que contiene debe ser su dominio (es decir, el mismo origen).
Tenga en cuenta que esto interrumpirá los casos en los que se accede a su sitio desde un marcador, un enlace dentro de un correo o similar, ya que en este caso no se enviará Referer . Pero en ningún caso, simplemente debe aceptar un Referer vacío (a menos que tenga un encabezado Origin no vacío) ya que es fácil de crear para un atacante.
También debe asegurarse de que sus comprobaciones para el dominio sean correctas. Esto es, si su sitio es www.example.com , no debe aceptar Referer como http://www.example.com.attacker.com o http://www.attacker.com/www.example.com o http://www-example.com .
También debe asegurarse de que el atacante no pueda usar otras funciones (o errores) en su aplicación como trampolín para crear una solicitud personalizada con carga maliciosa pero con el mismo origen Referer . Como Arminius bien señalado en un comentario, los redireccionamientos abiertos pueden ser un trampolín. Por lo tanto, debe asegurarse de que todas las solicitudes al dominio tengan un Referer del mismo origen o que las partes que puedan necesitar aceptar un Referer de origen cruzado no se puedan utilizar como trampolín.
Para obtener más información acerca de este método de protección contra CSRF y sobre sus problemas potenciales, consulte en Forgery de solicitud de sitios cruzados (CSRF) Prevention Cheat Sheet de OWASP.