El intercambio de recursos de origen cruzado ( CORS ) es un mecanismo que permite solicitar recursos restringidos en una página web desde otro dominio fuera del dominio desde el que se sirvió el primer recurso. [1]
Una página web puede incrustar libremente imágenes, hojas de estilo , scripts, iframes y videos de origen cruzado . [2] Ciertas solicitudes "entre dominios", en particular las solicitudes Ajax , están prohibidas por defecto por la política de seguridad del mismo origen . CORS define una forma en la que un navegador y un servidor pueden interactuar para determinar si es seguro permitir la solicitud de origen cruzado. [3] Permite más 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 de CORS se incluye como parte del Fetch Living Standard de WHATWG . [4] Esta especificación describe cómo CORS se implementa actualmente en los navegadores. [5] Se publicó una especificación anterior como Recomendación del W3C . [6]
Resumen técnico
Para los métodos de solicitud Ajax y HTTP que pueden modificar datos (generalmente métodos HTTP distintos a GET, o para el uso de POST con ciertos tipos de MIME ), la especificación exige que los navegadores realicen una "verificación previa" de la solicitud, solicitando métodos admitidos del servidor con una solicitud HTTP OPTIONS. y luego, tras la "aprobación" del servidor, enviar la solicitud real con el método de solicitud HTTP real. Los servidores también pueden notificar a los clientes si las "credenciales" (incluidas las cookies y los datos de autenticación HTTP) deben enviarse con las solicitudes. [7]
Ejemplo simple
Supongamos que un usuario visita http://www.example.com y la página intenta realizar una solicitud de origen cruzado para obtener los datos del usuario 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.
- El navegador envía la solicitud GET con un
Origin
encabezado HTTP adicional a service.example.com que contiene el dominio que sirvió a la página principal:Origen: http://www.example.com
- El servidor de service.example.com puede responder con:
- Se permiten los datos solicitados junto con un
Access-Control-Allow-Origin
encabezado (ACAO) en su respuesta que indica que las solicitudes del origen. Por ejemplo, en este caso debería ser:Access-Control-Allow-Origin: http://www.example.com
- Los datos solicitados junto con un
Access-Control-Allow-Origin
encabezado (ACAO) con un comodín que indica que se permiten las solicitudes de todos los dominios:Acceso-Control-Permitir-Origen: *
- Una página de error si el servidor no permite una solicitud de origen cruzado
- Se permiten los datos solicitados junto con un
Una política comodín del mismo origen es apropiada cuando una página o respuesta de API se considera contenido completamente público y está destinada a ser accesible para todos, incluido cualquier código en cualquier sitio. Una fuente web disponible gratuitamente en un servicio de alojamiento público como Google Fonts es un ejemplo.
Una política comodín del mismo origen también se usa amplia y apropiadamente en el modelo de capacidad de objetos , donde las páginas tienen URL que no se pueden adivinar y están destinadas a ser accesibles para cualquiera que conozca el secreto.
El valor de "*" es especial porque no permite que las solicitudes proporcionen credenciales, lo que significa que no permite la autenticación HTTP, los certificados SSL del lado del cliente o el envío de cookies en la solicitud entre dominios. [8]
Tenga en cuenta que en la arquitectura CORS, el encabezado Access-Control-Allow-Origin lo establece el servicio web externo ( service.example.com ), no el servidor de aplicaciones web original ( www.example.com ). Aquí, service.example.com usa 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 pueden llevar a cabo acciones privilegiadas y recuperar información confidencial. Incluso si no es así, los atacantes pueden eludir cualquier control de acceso basado en IP mediante el proxy a través de los navegadores de los usuarios.
Ejemplo de verificación previa
Al realizar ciertos tipos de solicitudes Ajax entre dominios, los navegadores modernos que admiten CORS iniciarán una solicitud adicional de "verificación previa" para determinar si tienen permiso para realizar la acción. Las solicitudes de origen cruzado se revisan previamente de esta manera porque pueden tener implicaciones para los datos del usuario.
OPCIONES /Anfitrión: service.example.comOrigen: http://www.example.comMé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:
Access-Control-Allow-Origin: http://www.example.comMétodos de permiso de control de acceso: PUT, DELETE
A continuación, el navegador realizará la solicitud real. Si service.example.com no acepta solicitudes entre sitios de este origen, responderá con error a la solicitud OPTIONS y el navegador no realizará la solicitud real.
Encabezados
Los encabezados HTTP que se relacionan con CORS son:
Solicitar encabezados
Origin
Access-Control-Request-Method
Access-Control-Request-Headers
Encabezados de respuesta
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Soporte del navegador
CORS es compatible con todos los navegadores basados en los siguientes motores de diseño:
- Navegadores basados en Blink y Chromium ( Chrome 28+, [9] [10] Opera 15+, [9] Amazon Silk , WebView de Android 4.4+ y WebEngine de Qt )
- Gecko 1.9.1 (Firefox 3.5, [11] SeaMonkey 2.0 [12] ) y superior.
- MSHTML / Trident 6.0 (Internet Explorer 10) tiene soporte nativo. [13] MSHTML / Trident 4.0 y 5.0 (Internet Explorer 8 y 9) brindan soporte parcial a través del objeto XDomainRequest. [1]
- 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, [1] Google Chrome 3 y superior, posiblemente anterior). [dieciséis]
- Microsoft Edge Todas las versiones. [17]
Historia
El soporte de origen cruzado fue propuesto originalmente por Matt Oshry, Brad Porter y Michael Bodell de Tellme Networks en marzo de 2004 para su inclusión en VoiceXML 2.1 [18] para permitir solicitudes de datos de origen cruzado seguras por parte de 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. [19] 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 en camino hacia el estatus formal de Recomendación del W3C .
En mayo de 2006 se presentó el primer borrador de trabajo del W3C. [20] En marzo de 2009, el proyecto pasó a llamarse "Intercambio de recursos de origen cruzado" [21] y en enero de 2014 fue aceptado como Recomendación del W3C. [22]
CORS frente a JSONP
CORS se puede utilizar como una alternativa moderna al patrón JSONP . Los beneficios de CORS son:
- Si bien JSONP solo admite el
GET
método de solicitud, CORS también admite otros tipos de solicitudes HTTP. - CORS permite que un programador web use XMLHttpRequest regular , 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 está comprometido, CORS permite que los sitios web analicen manualmente las respuestas para aumentar la seguridad. [3]
La principal ventaja de JSONP fue su capacidad para trabajar en navegadores heredados que son anteriores al soporte CORS ( Opera Mini e Internet Explorer 9 y versiones anteriores). CORS ahora es compatible con la mayoría de los navegadores web modernos. [23]
Ver también
- Política de seguridad de contenido
- Mensajería entre documentos
Referencias
- ↑ a b c el 6 de julio de 2009 por Arun Ranganathan (6 de julio de 2009). "cross-site xmlhttprequest con CORS ✩ Mozilla Hacks - el blog del desarrollador web" . Hacks.mozilla.org . Consultado el 5 de julio de 2012 .
- ^ "Política del mismo origen / Acceso a la red de origen cruzado" . MDN.
- ^ a b "Ajax de dominio cruzado con intercambio de recursos de origen cruzado" . NCZOnline . Consultado el 5 de julio de 2012 .
- ^ "Obtener estándar de vida" .
- ^ "Minutas del grupo de trabajo de WebAppSec" .
- ^ "Intercambio de recursos entre orígenes" .
- ^ "xmlhttprequest entre sitios con CORS" . MOZILLA . Consultado el 5 de septiembre de 2012 .
- ^ Uso compartido de recursos de origen cruzado . W3.org. Consultado el 12 de abril de 2014.
- ^ a b "Parpadeo" . QuirksBlog. Abril de 2013 . Consultado el 4 de abril de 2013 .
- ^ "Google sigue su propio camino, bifurcando el motor de renderizado WebKit" . Ars Technica. Abril de 2013 . Consultado el 4 de abril de 2013 .
- ^ "Control de acceso HTTP (CORS) - MDN" . Developer.mozilla.org. Archivado desde el original el 27 de mayo de 2010 . Consultado el 5 de julio de 2012 .
- ^ "Gecko - MDN" . Developer.mozilla.org. 2012-06-08 . Consultado el 5 de julio de 2012 .
- ^ Tony Ross; Director del programa; Internet Explorer (9 de febrero de 2012). "CORS para XHR en IE10" . MSDN . Consultado el 14 de diciembre de 2012 .
- ^ David Honneffer, especialista en documentación (14 de junio de 2012). "12.00 para registro de cambios de UNIX" . Ópera. Archivado desde el original el 18 de junio de 2012 . Consultado el 5 de julio de 2012 .
- ^ David Honneffer, especialista en documentación (23 de abril de 2012). "Opera Software: soporte de especificaciones web en Opera Presto 2.10" . Opera.com . Consultado el 5 de julio de 2012 .
- ^ "59940: Bypass de uso compartido de recursos de origen cruzado de Apple Safari WebKit" . Osvdb.org. Archivado desde el original el 19 de julio de 2012 . Consultado el 5 de julio de 2012 .
- ^ "Guía del desarrollador de Microsoft Edge" .
- ^ "Lenguaje de marcado extensible de voz (VoiceXML) 2.1" . W3.org. 2004-03-23 . Consultado el 5 de julio de 2012 .
- ^ "Autorización de acceso de lectura a contenido XML mediante la Control de acceso?> Instrucción de procesamiento 1.0" . W3.org . Consultado el 5 de julio de 2012 .
- ^ "Autorización de acceso de lectura a contenido XML mediante la Control de acceso?> Instrucción de procesamiento 1.0 W3C - Borrador de trabajo 17 de mayo de 2006" . W3.org . Consultado el 17 de agosto de 2015 .
- ^ "Intercambio de recursos de origen cruzado - Borrador de trabajo del W3C 17 de marzo de 2009" . W3.org . Consultado el 17 de agosto de 2015 .
- ^ "Intercambio de recursos de origen cruzado - Recomendación del W3C 16 de enero de 2014" . W3.org . Consultado el 17 de agosto de 2015 .
- ^ "¿Cuándo puedo usar ... Intercambio de recursos de origen cruzado" . caniuse.com . Consultado el 12 de julio de 2012 .
enlaces externos
- Obtener estándar de vida (la especificación actual para CORS)
- Artículo de control de acceso HTTP (CORS) de MDN
- Configuración de CORS en Apache con encabezados de respuesta correctos que permitan que todo pase
- Información detallada de procedimientos para habilitar el soporte CORS en varios servidores (web)
- HTML5 Rocks explica cómo funciona CORS en detalle
- Guía de W3C CORS para desarrolladores
- Cómo deshabilitar CORS en navegadores basados en WebKit para obtener la máxima seguridad y privacidad
- Escáner de configuración incorrecta de CORS en línea