CORS es solo para evitar origen cruzado leyendo dentro del navegador .
Antes de que se implementara CORS en los navegadores, las solicitudes simples (es decir, carga de formularios, incrustación de imágenes, etc.) podían hacer solicitudes de origen cruzado (y, por lo tanto, también ataques CSRF ) puede mostrar la respuesta dentro del navegador pero no puede acceder a la respuesta desde JavaScript. Y XMLHTTPRequest y similar estaban restringidos para acceder solo al mismo origen, pero podían leer la respuesta en JavaScript al realizar una solicitud del mismo origen (Política del mismo origen).
CORS trata principalmente con la última restricción: si el servidor permite explícitamente el acceso de origen cruzado, entonces se permitirá a XHR de origen cruzado tanto enviar una solicitud como leer la respuesta desde JavaScript (como solo con el mismo origen antes). ). Y el navegador puede incluir cookies existentes y similares al realizar dicha solicitud entre sitios y, por lo tanto, hacer lecturas entre sitios dentro de una sesión previamente autenticada.
Pero, ¿qué significa esto para las aplicaciones fuera del navegador? Dado que no se espera que se usen como un vector de ataque para la lectura entre sitios, en primer lugar, son irrelevantes en el contexto de CORS. Por supuesto, si una aplicación de este tipo implementa un comportamiento similar al navegador y realmente admite solicitudes autenticadas entre sitios, también debería implementar las protecciones relevantes que tienen los navegadores, es decir, la política de origen y CORS.
Tenga en cuenta que CORS no reemplaza la autenticación. Un servidor todavía tiene que implementar la autenticación adecuada para restringir qué tipo de datos pueden recuperar los usuarios. Pero con CORS se pueden realizar solicitudes entre sitios que utilizan la autenticación existente para recuperar contenido protegido entre sitios, pero solo si lo permite la política de CORS.