Hay dos problemas con las solicitudes de dominios cruzados: si una solicitud llega al servidor y si una respuesta es visible para el script del cliente que emitió la solicitud. Las llamadas solicitudes "simples" (que utilizan un método "simple" e incluyen solo encabezados "simples") están garantizadas para llegar al servidor, pero su visibilidad del script del cliente aún depende de los encabezados CORS apropiados. Las solicitudes no simples no se envían inmediatamente al servidor; Primero, el navegador envía una solicitud de "verificación previa" (utilizando OPCIONES) y utiliza los encabezados en esa respuesta de verificación previa para decidir si enviar la solicitud real. Esto se debe a que las solicitudes no simples pueden alterar el estado del servidor y, por lo tanto, podrían causar daños incluso si el cliente tenía prohibido ver la respuesta.
Dejemos claro que el resultado de una solicitud de OPCIONES de verificación previa es nunca disponible para el script del cliente. El navegador solo lo utiliza de forma privada para decidir si realizar la solicitud real iniciada por el script:
SiescribióunscriptqueintentórealizarunasolicituddeOPCIONESactual(esdecir,visibleparaelcliente),estaríasujetoalasreglasCORSnormales:
varxhr=newXMLHttpRequest();xhr.open("OPTIONS", "http://cors-enabled-server.example.com/");
xhr.onload = function(e) { console.log(e); }
xhr.send();
Esta solicitud generará una verificación previa (porque OPTIONS no es un método simple) y la solicitud fallará , a menos que el servidor envíe una respuesta Access-Control-Allow-Methods: OPTIONS . Tenga en cuenta que esto genera una solicitud de OPCIONES de verificación previa, pero que la solicitud de OPCIONES de verificación previa es nunca visible para el script . El script solo puede ver la solicitud / respuesta de OPCIONES "real", que viene después de una verificación previa exitosa.
Segundo, preguntas:
Pero una solicitud HEAD no recibirá nada más que encabezados y un estado ... sin embargo, se bloqueará de manera efectiva.
Esto no es cierto: la visibilidad del resultado puede estar bloqueada, pero la solicitud no lo está. Esto se debe a que el método HEAD es un método simple de acuerdo con CORS y, por lo tanto, no necesita una verificación previa, como GET y POST:
Se dice que un método es un método simple si se trata de una coincidencia que distingue entre mayúsculas y minúsculas
para uno de los siguientes:
Una solicitud HEAD entre dominios simple todavía requiere una respuesta Access-Control-Allow-Origin aceptable, pero no requiere una verificación previa. Por lo tanto, una simple solicitud HEAD (es decir, una que no tenga encabezados especiales que requieran una verificación previa) siempre se enviará directamente al servidor.
OPCIONES, por otro lado, no es un método simple y debe ser aprobado por Access-Control-Allow-Methods en una respuesta de verificación previa. No confunda una solicitud de OPCIONES de preflight (que nunca está sujeta a CORS, pero solo es visible para el navegador, no el script) con una solicitud de OPCIONES de JavaScript (que es visible al cliente, pero solo si pasa los requisitos de CORS).
Para responder a la pregunta del título en tu título, " ¿Cómo podría ser una amenaza un JavaScript que hace una solicitud HEAD entre dominios? ": es una amenaza aproximadamente del orden de permitir un dominio cruzado Solicitud GET, ya que HEAD debe ser - de acuerdo con la especificación HTTP - lo mismo que hacer una solicitud GET, pero sin el cuerpo de la respuesta. Todavía existe la posibilidad de que se filtren muchos datos confidenciales a través de los encabezados y los códigos de estado.