Mitigación basada en tokens

Esta defensa es uno de los métodos más populares y recomendados para

mitigar CSRF. Se puede lograr con estado ( patrón de token sincronizador ) o
sin estado ( patrón de token basado en cifrado o hash ).

Utilice implementaciones CSRF incorporadas o

existentes para la protección CSRF
Las defensas de token de sincronizador se han integrado en muchos
marcos. Se recomienda encarecidamente investigar si el marco que está
utilizando tiene una opción para lograr la protección CSRF de forma
predeterminada antes de intentar construir su sistema de generación de tokens
personalizado. Por ejemplo, .NET tiene protección integrada que agrega un
token a los recursos vulnerables de CSRF. Usted es responsable de la
configuración adecuada (como la administración de claves y la administración
de tokens) antes de usar estas protecciones CSRF integradas que generan
tokens para proteger los recursos vulnerables de CSRF.

También se recomiendan componentes externos que agregan defensas CSRF

a las aplicaciones existentes. Ejemplos:

 Para Java: OWASP CSRF Guard o Spring Security

 Para PHP y Apache: Proyecto CSRFProtector

Patrón de token de sincronizador

Los tokens CSRF deben generarse en el lado del servidor. Se pueden generar
una vez por sesión de usuario o para cada solicitud. Los tokens por solicitud
son más seguros que los por sesión, ya que el rango de tiempo para que un
atacante explote los tokens robados es mínimo. Sin embargo, esto puede
generar problemas de usabilidad. Por ejemplo, la capacidad del navegador del
botón "Atrás" a menudo se ve obstaculizada ya que la página anterior puede
contener un token que ya no es válido. La interacción con esta página anterior
dará como resultado un evento de seguridad falso positivo CSRF en el
servidor. En la implementación del token por sesión después de la generación
inicial del token, el valor se almacena en la sesión y se usa para cada solicitud
posterior hasta que la sesión caduque.

Cuando el cliente emite una solicitud, el componente del lado del servidor debe
verificar la existencia y validez del token en la solicitud en comparación con el
token encontrado en la sesión del usuario. Si el token no se encontró dentro
de la solicitud, o el valor proporcionado no coincide con el valor dentro de la
sesión del usuario, entonces la solicitud debe ser cancelada, la sesión del
usuario finalizada y el evento registrado como un posible ataque CSRF en
progreso.
Los tokens CSRF deben ser:
 Único por sesión de usuario.
 Secreto
 Impredecible (gran valor aleatorio generado por un método seguro ).

Los tokens CSRF evitan CSRF porque sin el token, el atacante no puede crear
solicitudes válidas para el servidor de fondo.

Los tokens CSRF no deben transmitirse usando cookies.

El token CSRF se puede agregar a través de campos ocultos, encabezados y

se puede usar con formularios y llamadas AJAX. Asegúrese de que el token
no se filtre en los registros del servidor o en la URL. Los tokens CSRF en las
solicitudes GET se filtran potencialmente en varias ubicaciones, como el
historial del navegador, los archivos de registro, los dispositivos de red que
registran la primera línea de una solicitud HTTP y los encabezados Referer si
el sitio protegido se vincula a un sitio externo.

Por ejemplo:
<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken"
value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1
ZDZMGYwMGEwOA==">
[...]
</form>
Insertar el token CSRF en el encabezado de solicitud HTTP personalizado a
través de JavaScript se considera más seguro que agregar el token en el
parámetro de formulario de campo oculto porque usa encabezados de solicitud
personalizados .

Patrón de token basado en cifrado

El Patrón de Token Cifrado aprovecha un método de cifrado, en lugar del
método de comparación de validación de Token. Es más adecuado para
aplicaciones que no desean mantener ningún estado en el lado del servidor.

El servidor genera un token compuesto por el ID de sesión del usuario y una

marca de tiempo (para evitar ataques de repetición) utilizando una clave única
disponible solo en el servidor (se recomienda AES256-con modo GCM / GCM-
SIV. No se recomienda estrictamente el uso del modo ECB Si desea utilizar
cualquier otro modo de operación de cifrado de bloque,
consulte aquí y aquí para obtener más información). Este token se devuelve al
cliente y se incrusta en un campo oculto para formularios, en el encabezado /
parámetro de solicitud para solicitudes AJAX. Al recibir esta solicitud, el
servidor lee y descifra el valor del token con la misma clave utilizada para crear
el token.

Si el valor no se puede descifrar, esto sugiere un intento de intrusión (que debe

bloquearse y registrarse con fines de depuración o respuesta a
incidentes). Una vez descifrado, se valida el ID de sesión de los usuarios y la
marca de tiempo contenida en el token. La identificación de la sesión se
compara con el usuario conectado actualmente, y la marca de tiempo se
 compara con la hora actual para verificar que no esté más allá del tiempo de
expiración del token definido. Si el ID de sesión coincide y la marca de tiempo
está por debajo del tiempo de expiración del token definido, se permite la
solicitud.

La Cheat Sheet de Key Management contiene las mejores prácticas sobre la

administración de claves de cifrado.

Patrón de token basado en HMAC

La mitigación del patrón de token basado en HMAC también se logra sin
mantener ningún estado en el servidor. La protección CSRF basada
en HMAC funciona de manera similar a la protección CSRF basada en cifrado
con un par de diferencias menores

1. Utiliza una función HMAC fuerte (se recomienda SHA-256 o superior) en lugar de una
función de cifrado para generar el token.
2. El token consiste en un HMAC y una marca de tiempo.

A continuación se detallan los pasos para la implementación adecuada de la

protección CSRF basada en HMAC:

1. Genere el token \ Usando la tecla K, generar HMAC(session ID + timestamp) y agregue

el mismo valor de marca de tiempo que da como resultado su token CSRF.
2. Incluya el token ( es decir HMAC+timestamp ) \ Incluir token en un campo oculto para
formularios y en el campo de encabezado de solicitud / parámetro de cuerpo de
solicitud para solicitudes AJAX.
3. Validación del token \ Cuando se recibe la solicitud en el servidor, vuelva a generar
el token con la misma clave K (los parámetros son el ID de sesión de la solicitud y la
marca de tiempo en el token recibido). Si el HMAC en el token recibido y el generado
en este paso coinciden, verifique si la marca de tiempo recibida es menor que el
tiempo de vencimiento del token definido. Si ambos son exitosos, la solicitud se trata
como legítima y se puede permitir. De lo contrario, bloquee la solicitud y registre el
ataque con fines de respuesta a incidentes.

La Hoja de trucos de administración de claves contiene las mejores prácticas

sobre la administración de la clave HMAC.

Técnicas de defensa en profundidad

Atributo de cookies de SameSite
SameSite es un atributo de cookie (similar a HTTPOnly, Secure, etc.) que tiene
como objetivo mitigar los ataques CSRF. Se define en RFC6265bis . Este
atributo ayuda al navegador a decidir si envía cookies junto con las solicitudes
entre sitios. Los valores posibles para este atributo son Lax, Stricto None.
El valor estricto evitará que el navegador envíe la cookie al sitio de destino en
todo el contexto de navegación entre sitios, incluso cuando se sigue un enlace
regular. Por ejemplo, para un sitio web similar a GitHub, esto significaría que
si un usuario conectado sigue un enlace a un proyecto privado de GitHub
 publicado en un foro de discusión corporativo o correo electrónico, GitHub no
recibirá la cookie de sesión y el usuario no podrá para acceder al proyecto. Sin
embargo, el sitio web de un banco no quiere permitir que ninguna página
transaccional se vincule desde sitios externos, por lo que la bandera Estricto
sería lo más apropiado.

El valor predeterminado de Lax proporciona un equilibrio razonable entre

seguridad y usabilidad para los sitios web que desean mantener la sesión
iniciada por el usuario después de que el usuario llega desde un enlace
externo. En el escenario anterior de GitHub, la cookie de sesión se permitiría
al seguir un enlace regular desde un sitio web externo mientras se bloquea en
métodos de solicitud propensos a CSRF como POST. Solo las solicitudes de
sitios cruzados que se permiten en modo Lax son las que tienen navegaciones
de nivel superior y también son métodos HTTP seguros .

Para obtener más detalles sobre los SameSitevalores, consulte la

siguiente sección del rfc .
Ejemplo de cookies que usan este atributo:
Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict
Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax
Todos los navegadores de escritorio y casi todos los navegadores móviles
ahora admiten el SameSiteatributo. Para realizar un seguimiento de los
navegadores que lo implementan y el uso del atributo, consulte el
siguiente servicio . Tenga en cuenta que Chrome ha anunciado que marcarán
las cookies como SameSite=Laxpredeterminadas de Chrome 80 (con
vencimiento en febrero de 2020), y Firefox y Edge planean hacer lo
mismo. Además, Securese requerirá la bandera para las cookies que están
marcadas como SameSite=None.
Es importante tener en cuenta que este atributo debe implementarse como
un concepto adicional de defensa de capa en profundidad . Este atributo
protege al usuario a través de los navegadores que lo admiten, y también
contiene 2 formas de omitirlo como se menciona en la siguiente sección . Este
atributo no debe reemplazar tener un token CSRF. En cambio, debería
coexistir con ese token para proteger al usuario de una manera más sólida.

Verificación del origen con encabezados estándar

Hay dos pasos para esta mitigación, los cuales dependen del examen de un
valor de encabezado de solicitud HTTP.

1. Determinar el origen del que proviene la solicitud (origen de origen). Se puede hacer
a través de encabezados Origin o Referer.
2. Determinar el origen al que va la solicitud (origen de destino).

En el lado del servidor verificamos si ambos coinciden. Si lo hacen, aceptamos

la solicitud como legítima (lo que significa que es la misma solicitud de origen)
y si no lo hacen, descartamos la solicitud (lo que significa que la solicitud se
originó en un dominio cruzado). La confiabilidad en estos encabezados
proviene del hecho de que no pueden modificarse mediante programación
(usando JavaScript con una vulnerabilidad XSS) ya que caen en la lista
 de encabezados prohibidos , lo que significa que solo el navegador puede
configurarlos

Identificación del origen de origen (a través del encabezado

Origen / Referente)
Comprobación del encabezado de origen

Si el encabezado Origen está presente, verifique que su valor coincida con el

origen objetivo. A diferencia del Referer, el encabezado Origin estará presente
en las solicitudes HTTP que se originan en una URL HTTPS.

Comprobación del encabezado de referencia

Si el encabezado Origen no está presente, verifique que el nombre de host en
el encabezado Referer coincida con el origen objetivo. Este método de
mitigación de CSRF también se usa comúnmente con solicitudes no
autenticadas, como las solicitudes realizadas antes de establecer un estado
de sesión, que es necesario para realizar un seguimiento de un token de
sincronización.

En ambos casos, asegúrese de que la verificación del origen del objetivo sea
sólida. Por ejemplo, si su sitio
está example.orgseguro example.org.attacker.com, no pase su verificación de
origen (es decir, haga coincidir el origen / después del origen para asegurarse
de que coincida con el origen completo).
Si ninguno de estos encabezados está presente, puede aceptar o bloquear la
solicitud. Recomendamos el bloqueo . Alternativamente, es posible que
desee registrar todas esas instancias, monitorear sus casos de uso /
comportamiento y luego comenzar a bloquear las solicitudes solo después de
obtener suficiente confianza.

Identificando el origen de destino

Puede pensar que es fácil determinar el origen del objetivo, pero con
frecuencia no lo es. El primer pensamiento es simplemente tomar el origen de
destino (es decir, su nombre de host y puerto #) de la URL en la solicitud. Sin
embargo, el servidor de aplicaciones con frecuencia se encuentra detrás de
uno o más servidores proxy y la URL original es diferente de la URL que el
servidor de aplicaciones realmente recibe. Si sus usuarios acceden
directamente a su servidor de aplicaciones, entonces usar el origen en la URL
está bien y ya está todo listo.
Si está detrás de un proxy, hay una serie de opciones a considerar.

 Configure su aplicación para que simplemente conozca su origen de

destino: es su aplicación, para que pueda encontrar su origen de destino y
establecer ese valor en alguna entrada de configuración del servidor. Este
sería el enfoque más seguro como su lado del servidor definido, por lo que es
un valor confiable. Sin embargo, esto podría ser problemático de mantener si
su aplicación se implementa en muchos lugares, por ejemplo, desarrollo,
prueba, control de calidad, producción y posiblemente varias instancias de
 producción. Establecer el valor correcto para cada una de estas situaciones
puede ser difícil, pero si puede hacerlo a través de alguna configuración central
y proporcionar sus instancias para obtener valor, ¡es genial! ( Nota: asegúrese
de que el almacén de configuración centralizada se mantenga de forma segura
porque la mayor parte de su defensa CSRF depende de ello).

 Utilice el valor del encabezado Host: si prefiere que la aplicación encuentre

su propio destino para que no tenga que configurarse para cada instancia
implementada, le recomendamos que utilice la familia de encabezados
Host. El propósito del encabezado Host es contener el origen objetivo de la
solicitud. Pero, si su servidor de aplicaciones está sentado detrás de un proxy,
el valor del encabezado del Host probablemente cambie al origen de destino
de la URL detrás del proxy, que es diferente de la URL original. Este origen de
encabezado de Host modificado no coincidirá con el origen de origen en los
encabezados de origen o referencia originales.

 Use el valor del encabezado X-Fordered-Host: para evitar el problema de

que el proxy altere el encabezado del host, hay otro encabezado llamado X-
Fordered-Host, cuyo propósito es contener el valor del encabezado del host
original que recibió el proxy. La mayoría de los proxys pasarán el valor del
encabezado Host original en el encabezado X-Fordered-Host. Por lo tanto, es
probable que el valor del encabezado sea el valor de origen de destino que
necesita comparar con el origen de origen en el encabezado Origen o
Referente.

Esta mitigación funciona correctamente cuando los encabezados de origen o

referencia están presentes en las solicitudes. Aunque estos encabezados se
incluyen la mayoría de las veces, hay pocos casos de uso en los que no se
incluyen (la mayoría de ellos son por razones legítimas para salvaguardar la
privacidad de los usuarios / sintonizar el ecosistema de los navegadores). A
continuación se enumeran algunos casos de uso:

 Internet Explorer 11 no agrega el encabezado Origin en una solicitud CORS en sitios

de una zona de confianza. El encabezado Referer seguirá siendo la única indicación
del origen de la IU. Vea las siguientes referencias en stackoverflow aquí y aquí .
 En una instancia que sigue a un origen cruzado de redireccionamiento 302 , Origen
no se incluye en la solicitud redirigida porque eso puede considerarse información
confidencial que no debe enviarse al otro origen.
 Existen algunos contextos de privacidad en los que Origen está configurado como
"nulo". Por ejemplo, consulte lo siguiente aquí .
 El encabezado de origen se incluye para todas las solicitudes de origen cruzado pero
para las mismas solicitudes de origen, en la mayoría de los navegadores solo se
incluye en POST / DELETE / PUT Nota: aunque no es ideal, muchos desarrolladores
usan solicitudes GET para realizar operaciones de cambio de estado.
 El encabezado de referencia no es una excepción. Existen múltiples casos de uso en
los que también se omite el encabezado de referencia ( 1 , 2 , 3 , 4 y 5 ). Los
equilibradores de carga, los servidores proxy y los dispositivos de red integrados
también son conocidos por eliminar el encabezado de referencia debido a razones de
privacidad al registrarlos.

Por lo general, un porcentaje menor del tráfico cae dentro de las categorías
anteriores ( 1-2% ) y ninguna empresa querría perder este tráfico. Una de las
técnicas populares utilizadas en Internet para hacer que esta técnica sea más
útil es aceptar la solicitud si el origen / referencia coincide con su lista
configurada de dominios "O" un valor nulo (ejemplos aquí . El valor nulo es
para cubrir los casos límite mencionados anteriormente donde estos
encabezados no se envían). Tenga en cuenta que los atacantes pueden
explotar esto, pero las personas prefieren usar esta técnica como una medida
de defensa en profundidad debido al menor esfuerzo que implica desplegarla.

Cookie de envío doble

Si mantener el estado para el token CSRF en el lado del servidor es
problemático, una defensa alternativa es utilizar la técnica de cookies de doble
envío. Esta técnica es fácil de implementar y no tiene estado. En esta técnica,
enviamos un valor aleatorio tanto en una cookie como en un parámetro de
solicitud, con el servidor verificando si el valor de la cookie y el valor de la
solicitud coinciden. Cuando un usuario visita (incluso antes de autenticarse
para evitar el inicio de sesión CSRF), el sitio debe generar un valor
pseudoaleatorio (criptográficamente fuerte) y establecerlo como una cookie en
la máquina del usuario separada del identificador de sesión. El sitio requiere
que cada solicitud de transacción incluya este valor pseudoaleatorio como un
valor de formulario oculto (u otro parámetro / encabezado de solicitud). Si
ambos coinciden en el lado del servidor, el servidor lo acepta como una
solicitud legítima y, si no lo hacen,

Debido a que los subdominios pueden escribir cookies en los dominios

principales y a que las cookies se pueden configurar para el dominio a través
de conexiones HTTP simples, esta técnica funciona siempre que esté seguro
de que sus subdominios están completamente protegidos y solo aceptan
conexiones HTTPS.

Para mejorar la seguridad de esta solución, incluya el token en una cookie

cifrada, que no sea la cookie de autenticación (ya que a menudo se comparten
dentro de los subdominios), y luego, en el lado del servidor, hágalo coincidir
(después de descifrar la cookie cifrada) con el token oculto campo de
formulario o parámetro / encabezado para llamadas ajax. Esto funciona porque
un subdominio no tiene forma de sobrescribir una cookie cifrada correctamente
diseñada sin la información necesaria, como la clave de cifrado.

Una alternativa más simple a una cookie encriptada es mezclar el token con
una sal secreta conocida solo por el servidor y colocar este valor en una
cookie. Esto es similar a una cookie encriptada (ambas requieren
conocimiento que solo el servidor posee), pero es menos computacionalmente
intensivo que encriptar y desencriptar la cookie. Ya sea que se use cifrado o
un hash salado, un atacante no podrá recrear el valor de la cookie desde el
token simple sin conocer los secretos del servidor.
 Cookie con prefijo __Host-
Otra solución para este problema es el uso de Cookie Prefixescookies con
token CSRF. Si la cookie tiene un __Host-prefijo, por ejemplo Set-Cookie:
__Host-token=RANDOM; path=/; Secure, la cookie:

 No se puede (sobre) escribir desde otro subdominio.

 Debe tener el camino de /.
 Debe estar marcado como Seguro (es decir, no se puede enviar a través de HTTP
sin cifrar).

Sin embargo, a partir de enero de 2020, IE y Edge no admiten los prefijos de

cookies .

Consulte la Red de desarrolladores de Mozilla y el borrador de IETF para

obtener más información sobre los prefijos de cookies.

Uso de encabezados de solicitud personalizados

Agregar tokens CSRF, una cookie y un valor de envío doble, un token
encriptado u otra defensa que implique cambiar la interfaz de usuario con
frecuencia puede ser complejo o problemático. Una defensa alternativa que es
particularmente adecuada para los puntos finales AJAX o API es el uso de
un encabezado de solicitud personalizado . Esta defensa se basa en
la restricción de la política del mismo origen (SOP) de que solo se puede usar
JavaScript para agregar un encabezado personalizado, y solo dentro de su
origen. De forma predeterminada, los navegadores no permiten que JavaScript
realice solicitudes de origen cruzado con encabezados personalizados.

Si este es el caso de su sistema, simplemente puede verificar la presencia de

este encabezado y valor en todos los puntos finales AJAX del lado del servidor
para protegerse contra los ataques CSRF. Este enfoque tiene la doble ventaja
de que generalmente no requiere cambios en la interfaz de usuario y no
introduce ningún estado del lado del servidor, lo cual es particularmente
atractivo para los servicios REST. Siempre puede agregar su
propio encabezado y valor personalizados si así lo prefiere.

Obviamente, esta técnica funciona para llamadas AJAX y aún debe

necesitar <form>etiquetas de protección con los enfoques descritos en este
documento, como los tokens. Además, la configuración de CORS también
debe ser robusta para que esta solución funcione de manera efectiva (ya que
los encabezados personalizados para solicitudes provenientes de otros
dominios activan una verificación CORS previa al vuelo).

Defensa CSRF basada en la interacción del usuario

Si bien todas las técnicas a las que se hace referencia aquí no requieren
ninguna interacción del usuario, a veces es más fácil o más apropiado
involucrar al usuario en la transacción para evitar operaciones no autorizadas
(falsificadas a través de CSRF o de otra manera). Los siguientes son algunos
 ejemplos de técnicas que pueden actuar como una fuerte defensa CSRF
cuando se implementan correctamente.

 Re-Autenticación (contraseña o más segura)

 Token de una sola vez
 CAPTCHA

Si bien se trata de una defensa CSRF muy fuerte, puede crear un impacto
significativo en la experiencia del usuario. Como tal, generalmente solo se
usarían para operaciones críticas de seguridad (como cambio de contraseña,
transferencias de dinero, etc.), junto con las otras defensas discutidas en esta
hoja de trucos.

Iniciar sesión CSRF

La mayoría de los desarrolladores tienden a ignorar la vulnerabilidad CSRF en
los formularios de inicio de sesión, ya que suponen que CSRF no sería
aplicable en los formularios de inicio de sesión porque el usuario no está
autenticado en esa etapa, sin embargo, esta suposición no siempre es
cierta. Las vulnerabilidades CSRF aún pueden ocurrir en formularios de inicio
de sesión donde el usuario no está autenticado, pero el impacto y el riesgo son
diferentes.

Por ejemplo, si un atacante usa CSRF para autenticar a una víctima en un sitio
web de compras utilizando la cuenta del atacante, y luego la víctima ingresa la
información de su tarjeta de crédito, un atacante puede comprar artículos
usando los datos de la tarjeta almacenados de la víctima. Para obtener más
información sobre el inicio de sesión CSRF y otros riesgos, consulte la sección
3 de este documento.

El CSRF de inicio de sesión puede mitigarse creando sesiones previas

(sesiones antes de que un usuario se autentique) e incluyendo tokens en el
formulario de inicio de sesión. Puede usar cualquiera de las técnicas
mencionadas anteriormente para generar tokens. Recuerde que las sesiones
previas no pueden pasar a sesiones reales una vez que el usuario está
autenticado: la sesión debe destruirse y debe realizarse una nueva para
evitar ataques de fijación de sesión . Esta técnica se describe en Defensas
sólidas para la falsificación de solicitudes entre sitios, sección 4.1 .

Si los subdominios bajo su dominio maestro no son confiables en su modelo

de amenaza, es difícil mitigar el inicio de sesión CSRF. Una validación estricta
de encabezado de referencia de subdominio y nivel de ruta se puede utilizar
en estos casos para mitigar CSRF en formularios de inicio de sesión hasta
cierto punto.

Ejemplo de referencia de Java

El siguiente filtro web JEE proporciona una referencia de ejemplo para algunos
de los conceptos descritos en esta hoja de referencia. Implementa las
siguientes mitigaciones sin estado ( OWASP CSRFGuard , cubre un enfoque
con estado).

 Verificación del mismo origen con encabezados estándar

 Cookie de doble envío
 Atributo de cookie SameSite

Tenga en cuenta que solo actúa como una muestra de referencia y no está
completa (por ejemplo: no tiene un bloque para dirigir el flujo de control cuando
la verificación de origen y encabezado de referencia tiene éxito ni tiene una
validación de nivel de puerto / host / protocolo para el encabezado de
referencia ) Se recomienda a los desarrolladores que creen su mitigación
completa sobre esta muestra de referencia. Los desarrolladores también
deben implementar comprobaciones de autenticación o autorización estándar
antes de verificar CSRF.

La fuente completa se encuentra aquí y proporciona un POC ejecutable.

Orientación de JavaScript para la

inclusión automática de tokens CSRF
como encabezado de solicitud AJAX
La siguiente guía considera que los métodos GET , HEAD y OPTIONS son
operaciones seguras. Por lo tanto , las llamadas AJAX del
método GET , HEAD y OPTIONS no necesitan agregarse con un encabezado
de token CSRF. Sin embargo, si los verbos se usan para realizar operaciones
de cambio de estado, también requerirán un encabezado de token CSRF
(aunque esta es una mala práctica y debe evitarse).

Los métodos POST , PUT , PATCH y DELETE , que son verbos que cambian
de estado, deben tener un token CSRF adjunto a la solicitud. La siguiente guía
demostrará cómo crear anulaciones en las bibliotecas de JavaScript para que
los tokens CSRF se incluyan automáticamente con cada solicitud de AJAX
para los métodos de cambio de estado mencionados anteriormente.

Almacenar el valor del token CSRF en el DOM

Se puede incluir un token CSRF en la <meta>etiqueta como se muestra a
continuación. Todas las llamadas posteriores en la página pueden extraer el
token CSRF de esta <meta>etiqueta. También se puede almacenar en una
variable de JavaScript o en cualquier lugar del DOM. Sin embargo, no se
recomienda almacenarlo en cookies o en el almacenamiento local del
navegador.
El siguiente fragmento de código se puede utilizar para incluir un token CSRF
como <meta>etiqueta:
<meta name="csrf-token" content="{{ csrf_token() }}">
La sintaxis exacta de rellenar el atributo de contenido dependerá del lenguaje
de programación de back-end de su aplicación web.
Anulación de valores predeterminados para
establecer encabezado personalizado
Varias bibliotecas de JavaScript permiten anular la configuración
predeterminada para que se agregue un encabezado automáticamente a todas
las solicitudes de AJAX.

XMLHttpRequest (JavaScript nativo)

El método open () de XMLHttpRequest se puede anular para establecer
el anti-csrf-tokenencabezado siempre open()que se invoque el método a
continuación. La función csrfSafeMethod()definida a continuación filtrará los
métodos HTTP seguros y solo agregará el encabezado a los métodos HTTP
inseguros.
Esto se puede hacer como se demuestra en el siguiente fragmento de código:
<script type="text/javascript">
var csrf_token = document.querySelector("meta[name='csrf-
token']").getAttribute("content");
function csrfSafeMethod(method) {
// these HTTP methods do not require CSRF protection
return (/^(GET|HEAD|OPTIONS)$/.test(method));
}
var o = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(){
var res = o.apply(this, arguments);
var err = new Error();
if (!csrfSafeMethod(arguments[0])) {
this.setRequestHeader('anti-csrf-token', csrf_token);
}
return res;
};
</script>

AngularJS
AngularJS permite configurar encabezados predeterminados para
operaciones HTTP. Puede encontrar más documentación en la documentación
de AngularJS para $ httpProvider .
<script>
var csrf_token = document.querySelector("meta[name='csrf-
token']").getAttribute("content");

var app = angular.module("app", []);

app.config(['$httpProvider', function ($httpProvider) {

$httpProvider.defaults.headers.post["anti-csrf-token"] =
csrf_token;
$httpProvider.defaults.headers.put["anti-csrf-token"] = csrf_token;
$httpProvider.defaults.headers.patch["anti-csrf-token"] =
csrf_token;
// AngularJS does not create an object for DELETE and TRACE methods
by default, and has to be manually created.
 $httpProvider.defaults.headers.delete = {
"Content-Type" : "application/json;charset=utf-8",
"anti-csrf-token" : csrf_token
};
$httpProvider.defaults.headers.trace = {
"Content-Type" : "application/json;charset=utf-8",
"anti-csrf-token" : csrf_token
};
}]);
</script>
Este fragmento de código ha sido probado con AngularJS versión 1.7.7.

Axios
Axios nos permite establecer encabezados predeterminados para las acciones
POST, PUT, DELETE y PATCH.
<script type="text/javascript">
var csrf_token = document.querySelector("meta[name='csrf-
token']").getAttribute("content");

axios.defaults.headers.post['anti-csrf-token'] = csrf_token;
axios.defaults.headers.put['anti-csrf-token'] = csrf_token;
axios.defaults.headers.delete['anti-csrf-token'] = csrf_token;
axios.defaults.headers.patch['anti-csrf-token'] = csrf_token;

// Axios does not create an object for TRACE method by default, and has
to be created manually.
axios.defaults.headers.trace = {}
axios.defaults.headers.trace['anti-csrf-token'] = csrf_token
</script>
Este fragmento de código ha sido probado con Axios versión 0.18.0.

JQuery
JQuery expone una API llamada $ .ajaxSetup () que se puede usar para
agregar el anti-csrf-tokenencabezado a la solicitud AJAX. La documentación
de la API $.ajaxSetup()se puede encontrar aquí. La
función csrfSafeMethod()definida a continuación filtrará los métodos HTTP
seguros y solo agregará el encabezado a los métodos HTTP inseguros.
Puede configurar JQuery para agregar automáticamente el token a todos los
encabezados de solicitud adoptando el siguiente fragmento de código. Esto
proporciona una protección CSRF simple y conveniente para sus aplicaciones
basadas en AJAX:
<script type="text/javascript">
var csrf_token = $('meta[name="csrf-token"]').attr('content');

function csrfSafeMethod(method) {
// these HTTP methods do not require CSRF protection
return (/^(GET|HEAD|OPTIONS)$/.test(method));
}

$.ajaxSetup({
beforeSend: function(xhr, settings) {
if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
 xhr.setRequestHeader("anti-csrf-token", csrf_token);
}
}
});
</script>
Este fragmento de código ha sido probado con jQuery versión 3.3.1.

Referencias
CSRF
OWASP Falsificación de solicitudes entre sitios (CSRF) PortSwigger Web
Security Academy Mozilla Web Security Cheat Sheet Conceptos erróneos
comunes de prevención de CSRF Defensas sólidas para falsificaciones de
solicitudes entre sitios