Uso compartido de recursos multiorigen (CORS)

Configuración Muestras de configuración

La política de mismo origen es una política de seguridad para las aplicaciones web del lado del cliente (como los navegadores web) que busca evitar interacciones entre recursos de diferentes orígenes. Si bien es útil para prevenir comportamientos maliciosos, esta medida de seguridad también evita interacciones legítimas entre orígenes conocidos. Por ejemplo, es posible que una secuencia de comandos de una página alojada en App Engine en example.appspot.com necesite usar recursos almacenados en un bucket de Cloud Storage en example.storage.. Sin embargo, debido a que se trata de dos orígenes diferentes, desde la perspectiva del navegador, este no permitirá que una secuencia de comandos de example.appspot.com obtenga recursos de example.storage..

Para sortear esta limitación, el Consorcio World Wide Web (W3C) desarrolló la especificación de Uso compartido de recursos entre dominios (CORS). Cloud Storage admite esta especificación, ya que te permite configurar tus buckets para que sean compatibles con CORS. Según el ejemplo anterior, puedes configurar el bucket example.storage. a fin de que un navegador pueda compartir sus recursos con secuencias de comandos de example.appspot.com.

Para obtener más información sobre los elementos de configuración de CORS, consulta la sección sobre la configuración de CORS de buckets.

Cómo funciona CORS

Existen dos tipos de solicitudes de CORS: simples y con verificación previa. Una solicitud simple se puede iniciar directamente. Una solicitud con verificación previa debe enviar una solicitud preliminar de “verificación previa” al servidor para obtener permiso antes de que se pueda continuar con la solicitud principal. Una solicitud tiene verificación previa si se cumple alguna de las siguientes circunstancias:

  • Usa métodos distintos de GET, HEAD o POST.
  • Usa el método POST con un Content-Type distinto de text/plain, application/x-www-form-urlencoded o multipart/form-data.
  • Establece encabezados personalizados. Por ejemplo, X-PINGOTHER.

El siguiente proceso ocurre cuando un navegador realiza una solicitud simple a Cloud Storage:

  1. El navegador agrega el encabezado Origin a la solicitud. El encabezado Origin contiene el origen del recurso que busca compartir los recursos del depósito de Cloud Storage, por ejemplo, Origin:https://www.example.appspot.com.

  2. Cloud Storage compara el método HTTP de la solicitud y el valor del encabezado Origin con la información de Métodos y Orígenes en la configuración de CORS del depósito de destino para ver si hay coincidencias. Si las hay, Cloud Storage incluye el encabezado Access-Control-Allow-Origin en su respuesta. El encabezado Access-Control-Allow-Origin contiene el valor del encabezado Origin de la solicitud inicial.

  3. El navegador recibe la respuesta y verifica si el valor de Access-Control-Allow-Origin coincide con el dominio especificado en la solicitud original. Si coincide, la solicitud tiene éxito. Si no hay coincidencia, o si el encabezado Access-Control-Allow-Origin no está presente en la respuesta, la solicitud falla.

En una solicitud con verificación previa, se completan los siguientes pasos primero. Si esto se realiza correctamente, luego sigue el siguiente proceso, que es el mismo de una solicitud simple:

  1. El navegador envía una solicitud OPTIONS que contiene el Requested Method y los Requested Headers de la solicitud principal.

  2. Cloud Storage responde con los valores de los métodos y encabezados de HTTP que permite el recurso de destino. Si alguno de los valores de método o encabezado en la solicitud de verificación previa no se encuentran en el conjunto de métodos y encabezados que permite el recurso de destino, la solicitud falla y la solicitud principal no se envía.

Esta una descripción simplificada de CORS. Para obtener una descripción más completa, consulta la especificación de recuperación.

Compatibilidad de Cloud Storage con CORS

Con Cloud Storage, puedes establecer la configuración de CORS solo a nivel de bucket. Puedes establecer una configuración de CORS para un bucket con una variedad de herramientas. Sin embargo, los diferentes extremos de Cloud Storage manejan las solicitudes de CORS de diferentes maneras:

  • En los extremos de la API de JSON, siempre se permiten las solicitudes de CORS y se muestran valores predeterminados en los encabezados de respuesta de CORS, sin importar la configuración establecida en el bucket.

  • En los extremos de la API de XML, solo se permiten solicitudes de CORS basadas en la configuración del bucket y se muestran valores de encabezado de CORS específicos en respuesta a esa configuración.

  • En el extremo de descarga del navegador autenticado storage.cloud.google.com, no se permiten las solicitudes de CORS. Ten en cuenta que, en la consola de Google Cloud, se proporciona este extremo para el vínculo de URL pública de cada objeto.

Puedes usar cualquiera de las siguientes URL de solicitud a la API de XML para obtener una respuesta de Cloud Storage que contenga los encabezados de CORS:

storage./BUCKET_NAME
BUCKET_NAME.storage.

Para obtener información sobre las URL de solicitud a la API de XML, consulta Solicita extremos.

Componentes de una configuración de CORS

Cuando usas la API de XML, los valores que estableces en la configuración de CORS del depósito determinan los encabezados de CORS que muestra Cloud Storage en una respuesta HTTP. Cuando usas la API de JSON, Cloud Storage no evalúa la configuración de tu bucket y, en su lugar, muestra los valores de encabezado predeterminados.

En la siguiente tabla, se describen los campos de una configuración de CORS y el comportamiento de respuesta de las APIs de XML y JSON. Para obtener información sobre cómo se usan estos campos, consulta Ejemplos de configuración de CORS.

Campo1 Descripción Comportamiento de respuesta de la API de XML Comportamiento de respuesta de la API de JSON
origin Especifica los orígenes que deseas permitir para el uso compartido de recursos entre dominios con este bucket de Cloud Storage. Por ejemplo, https://origin1.example.com. Si el origen en la solicitud de un navegador coincide con un origen en tu configuración de CORS, Cloud Storage muestra Access-Control-Allow-Origin al navegador. Si no hay ninguna coincidencia, Cloud Storage no incluye Access-Control-Allow-Origin en la respuesta. Puedes proporcionar un valor comodín que otorgue acceso a todos los orígenes: <Origin>*</Origin>. Cloud Storage muestra el encabezado Access-Control-Allow-Origin configurado en el origen de la solicitud.
method

Especifica los métodos de HTTP que deseas permitir para el uso compartido de recursos entre dominios con este bucket de Cloud Storage. El valor se muestra en el encabezado Access-Control-Allow-Methods en respuesta a solicitudes con verificación previa exitosas.

Dado que OPTIONS es un método estándar que los navegadores usan para iniciar solicitudes con verificación previa, no debes especificar OPTIONS en tu configuración de CORS.

Cloud Storage admite los siguientes métodos: DELETE, GET, HEAD, POST y PUT.

Cloud Storage compara los métodos enviados desde el navegador en el encabezado Access-Control-Request-Methods con la configuración de CORS del bucket. Si no hay coincidencia, Cloud Storage muestra un código de respuesta 200 sin encabezados de respuesta de CORS.

Cloud Storage muestra el encabezado Access-Control-Allow-Methods establecido en los siguientes métodos: DELETE, GET, HEAD, PATCH, POST, PUT.
responseHeader Especifica qué encabezados deseas permitir para el uso compartido de recursos entre dominios con este bucket de Cloud Storage. El valor se muestra en el encabezado Access-Control-Allow-Headers en respuesta a solicitudes con verificación previa exitosas. Para las solicitudes con verificación previa, Cloud Storage compara los encabezados enviados desde el navegador en el encabezado Access-Control-Request-Headers con la configuración de CORS del bucket. Si no hay coincidencia, Cloud Storage no muestra encabezados de respuesta de CORS. Cloud Storage muestra el encabezado Access-Control-Allow-Headers establecido igual a los valores especificados por el encabezado Access-Control-Request-Headers.
maxAgeSeconds (opcional) Especifica la cantidad de segundos que el navegador tiene permitido realizar solicitudes antes de que deba repetir la solicitud de verificación preliminar. Esto también se conoce como hora de vencimiento de la caché. Este valor se muestra en el encabezado Access-Control-Max-Age en las respuestas a las solicitudes con verificación previa. Por ejemplo, 3600 establece la hora de vencimiento de la caché en 1 hora. Cloud Storage muestra el encabezado Access-Control-Max-Age con la hora de vencimiento de la caché especificada. Si omites este campo, Cloud Storage muestra el valor predeterminado de 3600. Cloud Storage muestra el encabezado Access-Control-Max-Age con el valor predeterminado de 3600.

1 Los nombres documentados en la columna Campo son específicos de la API de JSON. Cuando uses la API de XML para establecer una configuración de CORS, usa el formato específico de XML.

Consideraciones adicionales

En la siguiente tabla, se describen las consideraciones para realizar solicitudes con credenciales o encabezados de control de acceso:

Propiedad o encabezado Descripción Comportamiento de respuesta de la API de XML Comportamiento de respuesta de la API de JSON
Credenciales Cookies, encabezados de autorización o certificados de cliente TLS. Cloud Storage nunca muestra el encabezado Access-Control-Allow-Credentials. La API de XML no admite las credenciales de CORS.

Para solicitudes simples, si se aprueba la solicitud de CORS, el encabezado Access-Control-Allow-Credentials se establece en “true”.

Para las solicitudes con validación previa, si Access-Control-Request-Method está vacío, Cloud Storage establece Access-Control-Allow-Credentials en “true” y rechaza la solicitud con 404 - Not Found.

Encabezados expuestos Para las solicitudes con verificación previa, el encabezado de la solicitud Access-Control-Request-Headers indica qué encabezados puede incluir una solicitud de CORS futura. El encabezado de respuesta Access-Control-Expose-Headers se incluye en la respuesta del servidor e indica al cliente qué encabezados se pueden exponer. En solicitudes simples, Access-Control-Expose-Headers enumera los valores de los encabezados de respuesta en la configuración de CORS. En solicitudes simples, Access-Control-Expose-Headers muestra los valores especificados en Access-Control-Request-Headers si forman parte de una lista de encabezados HTTP comunes.

Permite que los buckets accedan a recursos externos

A veces, es posible que desees permitir que las secuencias de comandos alojadas en Cloud Storage accedan a los recursos estáticos alojados en un sitio web externo a Cloud Storage. En esta situación, el sitio web entrega encabezados de CORS para permitir el acceso al contenido de storage..

Como práctica recomendada, debes dedicar un bucket específico para este acceso a los datos. Esta estrategia evita que tu sitio exponga de forma involuntaria los recursos estáticos en todo storage.. Por ejemplo, si deseas dedicar un bucket llamado mybucket para el acceso a los datos, debes hacer que el sitio web entregue el encabezado de CORS Access-Control-Allow-Origin: https://mybucket.storage. en lugar de Access-Control-Allow-Origin: https://storage..

Compatibilidad con CORS del cliente

La mayoría de los navegadores usan el objeto XMLHttpRequest para realizar una solicitud de dominio cruzado. XMLHttpRequest se encarga del trabajo de insertar los encabezados correctos y manejar la interacción de CORS con el servidor. No necesitas agregar ningún código nuevo para aprovechar la compatibilidad de los buckets de Cloud Storage con CORS.

¿Qué sigue?