He estado trabajando en un SPA clásico donde la aplicación de front-end vive en app.example.com mientras que la API vive en api.example.com , por lo que requiere el uso de solicitudes CORS. Ha configurado el servidor para devolver el encabezado CORS, funciona bien.
Siempre que una solicitud de AJAX no sea simple , el navegador realiza una solicitud adicional de OPTIONS al servidor para determinar si puede realizar la llamada con la carga útil. Encuentra solicitudes simples en MDN
La pregunta es: ¿Cuáles son los beneficios reales de hacer la solicitud de OPCIONES, especialmente en lo que respecta a la seguridad?
Algunos usuarios de mi aplicación tienen una latencia geográfica significativa y, dado que la caché de verificación previa no dura mucho, las solicitudes de verificación previa hacen que las latencias se multipliquen.
Espero hacer que las solicitudes POST sean simples, pero simplemente incrustar el Content-Type de la application/json niega. Una posible solución es "piratearla" usando text/plain o codificación en la URL. Por lo tanto, espero irme con una comprensión completa de lo que hacen las solicitudes de verificación previa de CORS para la seguridad web. Gracias.
Como se señaló en el artículo al que se vinculó:
Estos son los mismos tipos de solicitudes entre sitios que el contenido web ya puede emitir, y no se envían datos de respuesta al solicitante a menos que el servidor envíe un encabezado apropiado. Por lo tanto, los sitios que evitan la falsificación de solicitudes entre sitios no tienen nada nuevo que temer del control de acceso HTTP.
Básicamente, se hizo para asegurarse de que CORS no introduzca ningún medio adicional para realizar solicitudes entre dominios que, de lo contrario, se bloquearían sin CORS.
Por ejemplo, sin CORS, los siguientes tipos de contenido de formulario solo se pueden realizar entre dominios a través de una etiqueta <form> real, y no mediante una solicitud AJAX:
Por lo tanto, cualquier servidor que reciba una solicitud con uno de los tipos de contenido anteriores sabe que existe la posibilidad de que provenga de otro dominio y sabe tomar medidas contra ataques como Cross Site Request Forgery . Anteriormente, otros tipos de contenido, como application/json , solo podían crearse desde el mismo dominio, por lo que no era necesaria una protección adicional.
De manera similar, las solicitudes con encabezados adicionales (p. ej. X-Requested-With ) se habrían protegido previamente de manera similar, ya que solo podrían provenir del mismo dominio (una etiqueta <form> no puede agregar encabezados adicionales, que era la única forma anterior de hacer una cruz). -dominio POST). GET y POST también son los únicos métodos compatibles con un formulario . HEAD también se incluye aquí, ya que funciona de manera idéntica a GET, pero sin recuperar el cuerpo del mensaje.
Entonces, en pocas palabras, evitará que se realice una solicitud "no simple" en primer lugar, sin que se invoquen OPCIONES para garantizar que tanto el cliente como el servidor hablen el lenguaje CORS. Recuerde que la Política del mismo origen solo evita lecturas de diferentes orígenes, por lo que el mecanismo de verificación previa aún es necesario para evitar que se produzcan escrituras, es decir, que se ejecuten métodos inseguros en un escenario CSRF.
Es posible que pueda aumentar el rendimiento mediante el encabezado Access-Control-Max-Age . Detalles aquí .