Está bien, tanto la pregunta como la respuesta de Geir muestran una seria confusión, así que intentaré aclarar un poco las cosas ...
La política del mismo origen (SOP) es una función de seguridad del navegador que limita la interacción entre sitios web. En términos generales, evita que el sitio A vea el contenido del sitio B. Esto es importante, porque de lo contrario, si inicia sesión en un sitio como Facebook, cualquier otro sitio que quisiera podría ver e incluso tomar medidas en tu perfil de facebook Esto también se aplicaría a cosas como banca en línea, compras o administración de negocios. Es necesario para la seguridad de cualquier sitio web que requiera que inicie sesión o que se autentique de otra manera.
Parte de lo que previene el SOP es lo suficientemente simple de entender, como con XHR (XMLHttpRequest) y Fetch, donde impide que el sitio que lo solicita vea el contenido de la respuesta. Sin embargo, evita que se envíe la solicitud NOT , en la mayoría de los casos (de manera predeterminada, bloquea algunos tipos de solicitudes avanzadas entre sitios, como con encabezados). Después de todo, no tiene sentido evitar solicitudes simples (GET o POST con tipos de contenido estándar) porque un sitio web malicioso A que quiso atacar a B simplemente podría crear un formulario HTML que se envíe automáticamente a B con cualquier información que el atacante coloque, y Todas las cookies del usuario para B se incluirán con la solicitud. SOP también evita la mayor parte de la interacción entre iframes y sus páginas principales.
Sin embargo, hay algunas cosas que SOP no previene. Por ejemplo, una página web puede incluir secuencias de comandos e imágenes de sitios externos. Dado que la publicidad web casi siempre se realiza al cargar imágenes y scripts desde sitios externos (y, de hecho, el seguimiento web funciona de la misma manera), SOP no impide la publicidad en general. El SOP también no impide la CSRF , a menos que se use protección, como el uso de un token anti-CSRF, en cuyo caso el SOP es importante (de lo contrario, el sitio atacante podría leer el token anti-CSRF del sitio objetivo). , y luego enviarlo con la solicitud falsificada).
Intercambio de recursos de origen cruzado (CORS) es una forma de que el sitio B le diga a un navegador "hey, quiero que se relaje la política del mismo origen con respecto al sitio A, pero solo en Estas formas muy específicas ". Más específicamente, lo más básico que CORS puede hacer es permitir que las solicitudes estándar XHR y Fetch (que se realizan utilizando JS) lean el contenido de la respuesta, que normalmente no está permitido. También puede permitir cosas más complicadas, como permitir que el sitio A establezca encabezados de solicitud HTTP personalizados especificados (que normalmente no están permitidos) o tipos de contenido fuera de los que pueden enviar elementos HTML (que normalmente tampoco están permitidos). Por ejemplo, CORS podría usarse para permitir que dos sitios que confían entre sí (como security.stackexchange.com y stackoverflow.com) compartan información mediante solicitudes del lado del cliente. O podría usarse para proporcionar una API de servicio web que un sitio como Twitter puede usar para revelar mediante programación el contenido de los tweets a otros sitios, también en el lado del cliente (es decir, sin que el navegador tenga que pedir al servidor del sitio actual que envíe esa solicitud). it).
Sin embargo, para ser claros, CORS no "protege" nada en absoluto. Todo lo que CORS puede hacer es hacer agujeros en la protección de SOP. CORS fue desarrollado para proporcionar una forma más segura de evitar los SOP que las cosas que algunos sitios estaban haciendo en su lugar, como JSONP (que era un hack inteligente pero un desastre de seguridad). CORS le permite relajar el SOP solo de la forma que desee, solo para los sitios que desee.
Esperemos que también responda por qué tanto SOP como CORS son útiles. En general, no debe habilitar CORS en su servidor (es decir, enviar encabezados de respuesta de CORS) a menos que lo necesite, y si lo necesita, debe habilitarlo solo para las cosas que lo necesitan. He visto algunos sitios que utilizan CORS tan generosamente que, básicamente, han desactivado el SOP para todo su sitio, lo que permitiría que cualquier sitio malicioso en todo el Internet vea y controle el sitio mal configurado para cualquier usuario que haya iniciado sesión en él y haya visitado un sitio malicioso.