Compartir a través de

Compatibilidad con el uso compartido de recursos entre orígenes (CORS) para Azure Storage

  • Artículo

A partir de la versión 2013-08-15, los servicios de almacenamiento de Azure admiten Uso compartido de recursos entre orígenes (CORS) para los servicios Blob, Tabla y Cola. El servicio File admite CORS a partir de la versión 2015-02-21.

CORS es una característica de HTTP que permite que una aplicación web que se ejecuta en un dominio tenga acceso a recursos de otro dominio. Los exploradores web implementan una restricción de seguridad denominada directiva del mismo origen que impide que una página web llame a las API de otro dominio diferente; CORS proporciona una forma segura de permitir que un dominio (el dominio de origen) llame a las API de otro dominio. Consulte la especificación de CORS para obtener más información sobre CORS.

Puede establecer reglas de CORS individualmente para cada uno de los servicios de Azure Storage mediante una llamada a Establecer propiedades de Blob Service, Establecer propiedades del servicio de archivos, Establecer propiedades de Queue Service y Establecer propiedades de Table Service. Una vez establecidas las reglas de CORS para el servicio, se evaluará una solicitud autorizada correctamente realizada en el servicio desde un dominio diferente para determinar si se permite según las reglas que ha especificado.

Importante

CORS no es un mecanismo de autorización. Cualquier solicitud realizada en un recurso de almacenamiento cuando CORS está habilitado debe tener un encabezado de autorización válido o debe realizarse en un recurso público.

CORS es compatible con todos los tipos de cuenta de almacenamiento, excepto para las cuentas de almacenamiento de uso general v1 o v2 en el nivel de rendimiento Premium.

Descripción de las solicitudes de CORS

Una solicitud de CORS de un dominio de origen puede estar formada por dos solicitudes diferentes:

  • Una solicitud preparatoria, que consulta las restricciones de CORS impuestas por el servicio. La solicitud preparatoria es necesaria, a menos que el método de solicitud sea un método simple; es decir, GET, HEAD o POST.

  • La solicitud real, realizada en el recurso deseado.

Solicitud preparatoria

La solicitud preparatoria consulta las restricciones de CORS que el propietario de la cuenta ha establecido para el servicio de almacenamiento. El explorador web (u otro agente de usuario) envía una solicitud OPTIONS que incluye los encabezados, el método y el dominio de origen de la solicitud. El servicio de almacenamiento evalúa la operación deseada según un conjunto preconfigurado de reglas de CORS que especifican qué dominios de origen, métodos de solicitud y encabezados de solicitud se pueden especificar en una solicitud real para un recurso de almacenamiento.

Si se ha habilitado CORS para el servicio y hay una regla de CORS que coincide con la solicitud preparatoria, el servicio responde con el código de estado 200 (CORRECTO) e incluye los encabezados Access-Control necesarios en la respuesta.

Si CORS no se ha habilitado para el servicio o no hay ninguna regla de CORS que coincida con la solicitud preparatoria, el servicio responderá con el código de estado 403 (PROHIBIDO).

Si la solicitud OPTIONS no contiene los encabezados de CORS necesarios (los encabezados Origin y Access-Control-Request-Method), el servicio responderá con el código de estado 400 (Solicitud incorrecta).

Tenga en cuenta que una solicitud preparatoria se evalúa con respecto al servicio (Blob, File, Queue o Table) y no con el recurso solicitado. El propietario de la cuenta debe haber habilitado CORS estableciendo las propiedades de servicio de cuenta adecuadas para que la solicitud se realice correctamente.

Solicitud real

Una vez que la solicitud preparatoria se acepta y se devuelve una respuesta, el explorador enviará la solicitud real al recurso de almacenamiento. El explorador denegará inmediatamente la solicitud real si se rechazó la solicitud preparatoria.

La solicitud real se trata como una solicitud normal en el servicio de almacenamiento. La presencia del encabezado Origin indica que se trata de una solicitud CORS y el servicio comprobará las reglas de coincidencia de CORS. Si se encuentra una coincidencia, los encabezados Access-Control se agregan a la respuesta y se devuelven al cliente. Si no se encuentra ninguna coincidencia, no se devuelven los encabezados Access-Control de CORS.

Habilitación de CORS para Azure Storage

Las reglas de CORS se establecen en el nivel de servicio, por lo que debe habilitar o deshabilitar CORS para cada servicio (Blob, File, Queue y Table) por separado. De forma predeterminada, CORS está deshabilitado para todos los servicios. Para habilitar CORS, debe establecer las propiedades de servicio adecuadas con la versión 2013-08-15 o posterior para los servicios Blob, Queue y Table, o la versión 2015-02-21 o para el servicio de archivos. Para habilitar CORS, agregue reglas de CORS a las propiedades del servicio. Para obtener más información sobre cómo habilitar o deshabilitar CORS para un servicio y cómo establecer reglas de CORS, consulte Establecer propiedades de Blob Service, Establecer propiedades de File Service, Establecer propiedades de Table Service y Establecer propiedades de Queue Service.

Este es un ejemplo de una única regla de CORS, especificada a través de una Set Service Properties operación:

<Cors>
    <CorsRule>  
        <AllowedOrigins>http://*.contoso.com, http://www.fabrikam.com</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>  
        <ExposedHeaders>x-ms-meta-*</ExposedHeaders>  
        <MaxAgeInSeconds>200</MaxAgeInSeconds>  
    </CorsRule>  
<Cors>

A continuación se describen todos los elementos incluidos en la regla de CORS:

  • AllowedOrigins: los dominios de origen que pueden realizar una solicitud en el servicio de almacenamiento mediante CORS. El dominio de origen es el dominio desde el que se origina la solicitud. Tenga en cuenta que el origen debe tener una coincidencia exacta con distinción entre mayúsculas y minúsculas con el origen que el agente de usuario envía al servicio.

    Puede usar el carácter comodín '*' en lugar de un dominio especificado para permitir que todos los dominios de origen realicen solicitudes a través de CORS. También puede usar el carácter comodín en lugar de un subdominio para permitir que todos los subdominios de un dominio determinado realicen solicitudes a través de CORS. En el ejemplo anterior, todos los subdominios de pueden realizar solicitudes a través de contoso.com CORS, mientras que solo se permiten solicitudes del www subdominio de a través de fabrikam.com CORS.

  • AllowedMethods: los métodos (verbos de solicitud HTTP) que el dominio de origen puede usar para una solicitud de CORS. En el ejemplo anterior, solo se permiten las solicitudes PUT y GET.

  • AllowedHeaders: los encabezados de solicitud que el dominio de origen puede especificar en la solicitud de CORS. En el ejemplo anterior, se permiten todos los encabezados de metadatos que empiezan por x-ms-meta-data, x-ms-meta-target y x-ms-meta-abc. Tenga en cuenta que el carácter comodín '*' indica que se permite cualquier encabezado que empiece con el prefijo especificado.

  • ExposedHeaders: los encabezados de respuesta que se pueden enviar en la respuesta a la solicitud de CORS y que el explorador expone al emisor de la solicitud. En el ejemplo anterior, se pide al explorador que exponga todos los encabezados que empiecen con x-ms-meta.

  • MaxAgeInSeconds: el tiempo máximo que un explorador debe almacenar en memoria caché la solicitud preparatoria OPTIONS.

Los servicios de almacenamiento de Azure admiten especificar encabezados con prefijo para los elementos AllowedHeaders y ExposedHeaders. Para permitir una categoría de encabezados, puede especificar un prefijo común a esa categoría. Por ejemplo, si se especifica x-ms-meta* como un encabezado con prefijo se establece una regla que coincidirá con todos los encabezados que empiecen con x-ms-meta.

Se aplican las limitaciones siguientes a las reglas de CORS:

  • Puede especificar hasta cinco reglas de CORS por servicio de almacenamiento (blob, archivo, tabla y cola).

  • El tamaño máximo de todas las configuraciones de reglas de CORS en la solicitud, excepto las etiquetas XML, no debe superar los 2 KiB.

  • La longitud de un encabezado permitido, un encabezado expuesto o un origen permitido no debe superar los 256 caracteres.

  • Los encabezados permitidos y los encabezados expuestos pueden ser:

    • Encabezados literales, donde se proporciona el nombre exacto del encabezado, por ejemplo x-ms-meta-processed. Se puede especificar un máximo de 64 encabezados literales en la solicitud.
    • Encabezados con prefijo, donde se proporciona un prefijo del encabezado, como x-ms-meta-data*. Al especificar un prefijo de este modo se permite o se expone cualquier encabezado que comience con el prefijo indicado. Se puede especificar un máximo de dos encabezados con prefijo en la solicitud.

  • Los métodos (o los verbos HTTP) especificados en el elemento AllowedMethods deben ser acordes con los métodos admitidos por las API del servicio de almacenamiento de Azure. Los métodos admitidos son DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS y PUT.

Descripción de la lógica de evaluación de reglas de CORS

Cuando un servicio de almacenamiento recibe una solicitud preparatoria o real, evalúa esa solicitud según las reglas de CORS que ha establecido para el servicio mediante la operación Set Service Properties adecuada. Las reglas de CORS se evalúan en el orden en que se establecieron en el cuerpo de la solicitud de la operación Set Service Properties.

Las reglas de CORS se evalúan de la manera siguiente:

  1. Primero se comprueba el dominio de origen de la solicitud con los dominios enumerados para el elemento AllowedOrigins. Si el dominio de origen está incluido en la lista, o si se permiten todos los dominios con el carácter comodín '*', la evaluación de las reglas continúa. Si el dominio de origen no está incluido, se produce un error en la solicitud.

  2. A continuación, el método (o verbo HTTP) de la solicitud se comprueba con los métodos enumerados en el elemento AllowedMethods. Si el método está incluido en la lista, la evaluación de las reglas continúa; de lo contrario, se produce un error en la solicitud.

  3. Si la solicitud coincide con una regla en su dominio de origen y su método, se selecciona esa regla para procesar la solicitud y no se evalúa ninguna otra regla. Sin embargo, antes de que la solicitud se pueda realizar correctamente, todos los encabezados especificados en la solicitud se compara con los encabezados incluidos en el elemento AllowedHeaders. Si los encabezados enviados no coinciden con los encabezados permitidos, se produce un error en la solicitud.

Puesto que las reglas se procesan en el orden en que se encuentran en el cuerpo de la solicitud, las prácticas recomendadas indican que debe especificar las reglas más restrictivas en cuanto a los orígenes al principio de la lista, para que se evalúen en primer lugar. Especifique al final de la lista las reglas que sean menos restrictivas; por ejemplo, una regla para permitir todos los orígenes.

Ejemplo: evaluación de reglas de CORS

En el ejemplo siguiente se muestra un cuerpo de solicitud parcial correspondiente a una operación para establecer reglas de CORS para los servicios de almacenamiento. Consulte Establecer propiedades de Blob Service, Establecer propiedades del servicio de archivos, Establecer propiedades de Queue Service y Establecer propiedades de Table Service para obtener más información sobre cómo construir la solicitud.

<Cors>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>PUT,HEAD</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>*</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-client-request-id</AllowedHeaders>  
    </CorsRule>  
</Cors>

A continuación, considere las solicitudes de CORS siguientes:

Método Origen Encabezados de solicitud Coincidencia de regla Resultado
PUT http://www.contoso.com x-ms-blob-content-type Primera regla Correcto
GET http://www.contoso.com x-ms-blob-content-type Segunda regla Correcto
GET http://www.contoso.com x-ms-client-request-id Segunda regla Error

La primera solicitud coincide con la primera regla: el dominio de origen coincide con los orígenes permitidos, el método coincide con los métodos permitidos y el encabezado coincide con los encabezados permitidos. Por tanto, es correcta.

La segunda solicitud no coincide con la primera regla porque el método no coincide con los métodos permitidos. Sin embargo, coincide con la segunda regla, por lo que se realiza correctamente.

La tercera solicitud coincide con la segunda regla en su dominio de origen y método, por lo que no se evalúa ninguna regla más. Sin embargo, el encabezado x-ms-client-request-id no está permitido por la segunda regla, por lo que se produce un error en la solicitud, a pesar de que la semántica de la tercera regla habría permitido que se realizara correctamente.

Nota:

Aunque este ejemplo muestra una regla menos restrictiva antes que otra más restrictiva, en general la práctica recomendada es enumerar primero las reglas más restrictivas.

Descripción de cómo se establece el encabezado Vary

El encabezado Vary es un encabezado HTTP/1.1 estándar que consta de un conjunto de campos de encabezado de solicitud que aconsejan al explorador o al agente de usuario sobre los criterios seleccionados por el servidor para procesar la solicitud. El encabezado Vary se utiliza principalmente para el almacenamiento en memoria caché por parte de los servidores proxy, exploradores y redes CDN, que lo utilizan para determinar cómo se debe almacenar la respuesta en memoria caché. Para obtener información detallada, vea la especificación del Encabezado Vary.

Cuando el explorador u otro agente de usuario almacena en memoria caché la respuesta de una solicitud de CORS, el dominio de origen se almacena en memoria caché como el origen permitido. Cuando un segundo dominio emite la misma solicitud para un recurso de almacenamiento mientras la memoria caché está activa, el agente de usuario recupera el dominio de origen de la memoria caché. El segundo dominio no coincide con el dominio almacenado en memoria caché, por lo que se produce un error en la solicitud cuando de lo contrario se realizaría correctamente. En determinados casos, Azure Storage establece el Vary encabezado en Origin para indicar al agente de usuario que envíe la solicitud CORS posterior al servicio cuando el dominio solicitante difiere del origen almacenado en caché.

Azure Storage establece el Vary encabezado Origin en para las solicitudes GET/HEAD reales en los casos siguientes:

  • Cuando el origen de la solicitud coincide exactamente con el origen permitido definido por una regla de CORS. Para que sea una coincidencia exacta, la regla de CORS no puede incluir un carácter comodín '*'.

  • No hay ninguna regla que coincida con el origen de la solicitud, pero CORS se ha habilitado para el servicio de almacenamiento.

En caso de que una solicitud GET/HEAD coincida con una regla de CORS que permita todos los orígenes, la respuesta indica que se permiten todos los orígenes y la memoria caché del agente de usuario permitirá solicitudes posteriores de cualquier dominio de origen mientras la memoria caché esté activa.

Tenga en cuenta que para las solicitudes que utilizan otros métodos distintos de GET/HEAD, los servicios de almacenamiento no establecerá el encabezado Vary, ya que los agentes de usuario no almacenan en memoria caché las respuestas a estos métodos.

En la tabla siguiente se indica cómo responderá Almacenamiento de Azure a las solicitudes GET/HEAD según los casos mencionados anteriormente:

Encabezado Origin presente en la solicitud Reglas de CORS especificadas para este servicio Existe una regla de coincidencia que permite todos los orígenes (*) Existe una regla de coincidencia para una coincidencia exacta del origen La respuesta incluye el encabezado Vary establecido en Origin La respuesta incluye Access-Control-Allowed-Origin: "*" La respuesta incluye Access-Control-Exposed-Headers
No No No No No No No
No Sí No No Sí No No
No Sí Sí No No Sí Sí
Sí No No No No No No
Sí Sí No Sí Sí No Sí
Sí Sí No No Sí No No
Sí Sí Sí No No Sí Sí

Facturación de las solicitudes de CORS

Las solicitudes previas correctas se facturan si ha habilitado CORS para cualquiera de los servicios de almacenamiento de su cuenta (llamando a Set Blob Service Properties, Set Queue Service Properties, Set File Service Properties o Set Table Service Properties). Para minimizar los cargos, considere la posibilidad de establecer el elemento MaxAgeInSeconds de las reglas de CORS en un valor grande para que el agente de usuario almacene la solicitud en memoria caché.

Las solicitudes preparatorias erróneas no se cargan en cuenta.

Consulte también

Especificación de uso compartido de recursos entre orígenes de W3C