Intercambio de recursos entre diferentes orígenes

En informática, el intercambio de recursos de origen cruzado ( CORS, por sus siglas en inglés) es un mecanismo para eludir de forma segura la política del mismo origen ; es decir, permite que una página web acceda a recursos restringidos desde un servidor web en un nombre de dominio diferente al dominio que sirvió la página web.

Una página web puede incrustar libremente imágenes, hojas de estilo , scripts , iframes y vídeos de diferentes orígenes . Ciertas solicitudes HTTP "entre dominios" , especialmente las solicitudes Ajax , están prohibidas por defecto por la política de seguridad del mismo origen. CORS define una forma en que un navegador web y un servidor pueden interactuar para determinar si es seguro permitir la solicitud de origen cruzado. ^{[ 1 ]} Permite mayor libertad y funcionalidad que las solicitudes puramente del mismo origen, pero es más seguro que simplemente permitir todas las solicitudes de origen cruzado.

La especificación para CORS está incluida como parte del Fetch Living Standard del WHATWG . ^{[ 2 ]} Esta especificación describe cómo se implementa actualmente CORS en los navegadores. ^{[ 3 ]} Una especificación anterior se publicó como una recomendación del W3C . ^{[ 4 ]}

Para las solicitudes HTTP realizadas desde JavaScript que no se pueden realizar utilizando una etiqueta <form> que apunte a otro dominio o que contenga encabezados no incluidos en la lista de seguridad, la especificación exige que los navegadores realicen una "precomprobación" de la solicitud, solicitando al servidor los métodos compatibles con el método de solicitud HTTP OPTIONS y, posteriormente, tras la "aprobación" del servidor, enviando la solicitud real con el método de solicitud HTTP correspondiente. Los servidores también pueden notificar a los clientes si deben enviarse "credenciales" (incluidas las cookies y los datos de autenticación HTTP) con las solicitudes. ^{[ 5 ]}

Supongamos que un usuario visita http://www.example.com y la página intenta una solicitud de origen cruzado para obtener datos de http://service.example.com . Un navegador compatible con CORS intentará realizar una solicitud de origen cruzado a service.example.com de la siguiente manera.

1. El navegador envía la solicitud GET con un Originencabezado HTTP adicional a service.example.com que contiene el dominio que sirvió la página principal:

   Origen: http://www.example.com

2. El servidor en service.example.com envía una de estas tres respuestas:
   • Se permiten los datos solicitados junto con un Access-Control-Allow-Originencabezado (ACAO) en su respuesta que indique que las solicitudes provienen del origen. Por ejemplo, en este caso debería ser:

     Control de acceso-Permitir-origen: http://www.example.com

   • Los datos solicitados junto con un Access-Control-Allow-Originencabezado (ACAO) con un comodín que indica que se permiten las solicitudes de todos los dominios:

     Control de acceso-Permitir-Origen: *

   • Una página de error si el servidor no permite una solicitud de origen cruzado ^{[ 6 ]}

Una política de mismo origen con comodines es apropiada cuando se pretende que una página o respuesta de API sea accesible desde cualquier código en cualquier sitio. Un ejemplo de ello es una fuente web disponible gratuitamente en un servicio de alojamiento público como Google Fonts .

El valor "*" es especial porque no permite que las solicitudes proporcionen credenciales, lo que significa que no permite que se envíen autenticación HTTP, certificados SSL del lado del cliente o cookies en la solicitud entre dominios. ^{[ 7 ]}

Cabe destacar que, en la arquitectura CORS, el encabezado Access-Control-Allow-Origin lo establece el servicio web externo ( service.example.com ), no el servidor de la aplicación web original ( www.example.com ). En este caso, service.example.com utiliza CORS para permitir que el navegador autorice a www.example.com a realizar solicitudes a service.example.com .

Si un sitio especifica el encabezado "Access-Control-Allow-Credentials:true", los sitios de terceros podrían realizar acciones privilegiadas y recuperar información confidencial.

Al realizar ciertos tipos de solicitudes Ajax entre dominios, los navegadores modernos compatibles con CORS inician una solicitud previa adicional para determinar si tienen permiso para realizar la acción. Las solicitudes de origen cruzado se someten a esta verificación previa porque pueden afectar los datos del usuario.

OPCIONES / Host: service.example.com Origen: http://www.example.com Método de solicitud de control de acceso: PUT 

Si service.example.com está dispuesto a aceptar la acción, puede responder con los siguientes encabezados:

Control de acceso-Permitir-origen: http://www.example.com Métodos permitidos de control de acceso: PUT 

El navegador realizará entonces la solicitud. Si service.example.com no acepta solicitudes entre sitios desde este origen, responderá con un error a la solicitud OPTIONS y el navegador no realizará la solicitud.

Los encabezados HTTP relacionados con CORS son:

CORS es compatible con todos los navegadores basados ​​en los siguientes motores de renderizado:

• Navegadores basados ​​en Blink y Chromium ( Chrome 28+, ^{[ 8 ] [ 9 ]} Opera 15+, ^{[ 8 ]} Amazon Silk , WebView de Android 4.4+ y WebEngine de Qt )
• Gecko 1.9.1 (Firefox 3.5, ^{[ 10 ]} SeaMonkey 2.0 ^{[ 11 ]} ) y superior.
• MSHTML/Trident 6.0 (Internet Explorer 10) tiene soporte nativo. ^{[ 12 ]} MSHTML/Trident 4.0 y 5.0 (Internet Explorer 8 y 9) proporcionan soporte parcial a través del objeto XDomainRequest. ^{[ 13 ]}
• Los navegadores basados ​​en Presto (Opera) implementan CORS a partir de Opera 12.00 ^{[ 14 ]} y Opera Mobile 12, pero no Opera Mini . ^{[ 15 ]}
• WebKit (revisión inicial incierta, Safari 4 y superior, ^{[ 16 ]} Google Chrome 3 y superior, posiblemente anterior). ^{[ 17 ]}
• Microsoft Edge Todas las versiones. ^{[ 18 ]}

La compatibilidad con origen cruzado fue propuesta originalmente por Matt Oshry, Brad Porter y Michael Bodell de Tellme Networks en marzo de 2004 para su inclusión en VoiceXML 2.1 ^{[ 19 ]} para permitir solicitudes de datos seguras de origen cruzado por parte de los navegadores VoiceXML. El mecanismo se consideró de naturaleza general y no específico de VoiceXML y posteriormente se separó en una NOTA de implementación. ^{[ 20 ]} El Grupo de Trabajo de Aplicaciones Web del W3C, con la participación de los principales proveedores de navegadores, comenzó a formalizar la NOTA en un Borrador de Trabajo del W3C encaminado a convertirse en una Recomendación formal del W3C .

En mayo de 2006 se presentó el primer borrador de trabajo del W3C. ^{[ 21 ]} En marzo de 2009, el borrador pasó a llamarse "Intercambio de recursos de origen cruzado" ^{[ 22 ]} y en enero de 2014 fue aceptado como recomendación del W3C. ^{[ 23 ]}

La principal ventaja de JSONP era su capacidad para funcionar en navegadores antiguos anteriores al soporte de CORS ( Opera Mini e Internet Explorer 9 y versiones anteriores). Actualmente, la mayoría de los navegadores web modernos admiten CORS ^{[ 24 ]} y este puede utilizarse como una alternativa moderna al patrón JSONP . Los beneficios de CORS son:

• Si bien JSONP solo admite el GETmétodo de solicitud, CORS también admite otros tipos de solicitudes HTTP.
• CORS permite a un programador web utilizar XMLHttpRequest estándar , que admite un mejor manejo de errores que JSONP.
• Si bien JSONP puede causar problemas de secuencias de comandos entre sitios (XSS) cuando el sitio externo se ve comprometido, CORS permite que los sitios web analicen manualmente las respuestas para aumentar la seguridad. ^{[ 1 ]}

• Política de seguridad de contenido
• Mensajería entre documentos
• Fugas entre sitios

• Obtener Living Standard (la especificación actual para CORS)
• Configurar CORS en Apache con los encabezados de respuesta correctos permitiendo todo el paso
• Información detallada sobre cómo habilitar la compatibilidad con CORS en varios servidores (web).
• HTML5 Rocks explica en detalle cómo funciona CORS.
• Escáner de configuración incorrecta de CORS en línea. Archivado el 10 de agosto de 2020 en Wayback Machine.