Partage des ressources entre origines multiples (CORS)

Configuration Exemples de configuration

Le partage de ressources entre origines multiples (CORS, Cross-Origin Resource Sharing) permet aux applications Web côté client d'accéder aux ressources de différentes origines. Cloud Storage est compatible avec la spécification CORS, ce qui vous permet de configurer vos buckets pour partager des ressources de manière sécurisée avec des scripts provenant d'autres origines. Par exemple, vous pouvez utiliser CORS pour permettre à votre application Web https://example-app.appspot.com d'accéder à une ressource à l'origine https://example-data.storage.googleapis.com.

Pour plus d'informations sur les composants de la configuration CORS, consultez la page Définir la configuration CORS d'un bucket.

Fonctionnement du CORS

Utilisez CORS lorsque vous souhaitez que votre site Web récupère des fichiers, des images ou des scripts directement à partir d'un bucket Cloud Storage à l'aide d'une requête basée sur le navigateur.

Autoriser l'accès entre les domaines

Par défaut, les navigateurs Web appliquent une mesure de sécurité appelée règle d'origine identique. Le règlement d'origine identique empêche un script sur un site Web d'interagir avec des ressources sur un autre domaine. Bien que cela protège les utilisateurs contre les sites malveillants, cela bloque également les requêtes légitimes. Par exemple, si votre application Web https://example-app.appspot.com tente d'accéder à une ressource à l'origine https://example-data.storage.googleapis.com, le navigateur bloque la requête par défaut, car les domaines ne correspondent pas.

La spécification CORS permet aux serveurs d'indiquer au navigateur : "Je fais confiance à ce domaine spécifique, alors autorise la requête."

Cloud Storage vous permet de définir une configuration CORS sur votre bucket. Une fois configuré, Cloud Storage renvoie des en-têtes HTTP spécifiques au navigateur (tels que Access-Control-Allow-Origin) qui autorisent le navigateur à partager les ressources du bucket avec votre application Web.

Types de demandes

Les requêtes CORS fonctionnent de deux manières : simple et pré-vérifiée. Une requête simple est traitée directement, tandis qu'une requête pré-vérifiée envoie d'abord une requête préliminaire pour obtenir une autorisation.

Requêtes simples

Le processus suivant se produit lorsqu'un navigateur envoie une requête simple à Cloud Storage :

1. Le navigateur ajoute l'en-tête Origin à la requête. L'en-tête Origin contient l'origine de la ressource qui cherche à partager les ressources du bucket Cloud Storage, par exemple Origin:https://www.example-app.appspot.com.

2. Cloud Storage compare la méthode HTTP de la requête et la valeur de l'en-tête Origin aux informations sur les méthodes et les origines de la configuration CORS du bucket cible, afin de déterminer s'il existe des correspondances. Le cas échéant, Cloud Storage inclut l'en-tête Access-Control-Allow-Origin dans sa réponse. L'en-tête Access-Control-Allow-Origin contient la valeur de l'en-tête Origin de la requête initiale.

3. Le navigateur reçoit la réponse et vérifie si la valeur Access-Control-Allow-Origin correspond au domaine spécifié dans la requête d'origine. Si c'est le cas, la requête aboutit. Si la valeur ne correspond pas, ou si l'en-tête Access-Control-Allow-Origin n'est pas présent dans la réponse, la requête échoue.

Requêtes préliminaires

Une requête est pré-vérifiée si l'une des conditions suivantes est vraie :

• Elle utilise des méthodes autres que GET, HEAD ou POST.
• Elle utilise la méthode POST avec un paramètre Content-Type différent de text/plain, application/x-www-form-urlencoded ou multipart/form-data.
• Elle définit des en-têtes personnalisés. Par exemple, X-PINGOTHER.

Une requête pré-vérifiée accomplit d'abord les étapes ci-après. Si celles-ci se déroulent correctement, elle suit alors le même processus qu'une requête simple :

1. Le navigateur envoie une requête OPTIONS contenant les éléments Requested Method et Requested Headers de la requête principale.

2. Cloud Storage répond avec les valeurs des en-têtes et des méthodes HTTP autorisés par la ressource ciblée. Si l'une des valeurs de méthode ou d'en-tête de la requête de pré-vérification ne fait pas partie de l'ensemble de méthodes et d'en-têtes autorisés par la ressource ciblée, la requête échoue. La requête principale n'est alors pas envoyée.

Pour obtenir une description plus complète des requêtes CORS, consultez la spécification Fetch.

Compatibilité du CORS avec Cloud Storage

Cloud Storage vous permet de définir des configurations CORS au niveau du bucket. Les points de terminaison de l'API JSON et de l'API XML gèrent les requêtes CORS et renvoient les en-têtes de réponse différemment. Comprenez ces comportements pour configurer efficacement vos buckets :

• Les points de terminaison de l'API JSON autorisent toujours les requêtes CORS et renvoient des valeurs par défaut dans les en-têtes de réponse CORS, quelle que soit la configuration définie sur le bucket.

• Les points de terminaison de l'API XML n'acceptent que les requêtes CORS basées sur la configuration du bucket et renvoient des valeurs d'en-tête CORS spécifiques en réponse à cette configuration.

• Le point de terminaison de téléchargement du navigateur authentifié storage.cloud.google.com n'autorise pas les requêtes CORS. Notez que la console Google Cloud fournit ce point de terminaison pour le lien d'URL public de chaque objet.

Vous pouvez obtenir une réponse de Cloud Storage contenant les en-têtes CORS à l'aide de l'une des URL de requête de l'API XML suivantes :

storage.googleapis.com/BUCKET_NAME

BUCKET_NAME.storage.googleapis.com

Pour plus d'informations sur les URL de requête de l'API XML, consultez la page Points de terminaison de requêtes.

Composants d'une configuration CORS

Lorsque vous utilisez l'API XML, les valeurs que vous définissez dans la configuration CORS de votre bucket déterminent les en-têtes CORS renvoyés par Cloud Storage dans une réponse HTTP. Lorsque vous utilisez l'API JSON, Cloud Storage n'évalue pas la configuration de votre bucket et renvoie à la place des valeurs d'en-tête par défaut.

Le tableau suivant décrit les champs d'une configuration CORS et le comportement de réponse des API XML et JSON. Pour en savoir plus sur l'utilisation de ces champs, consultez les Exemples de configuration CORS.