Partage des ressources entre origines multiples (CORS)

Accéder à des exemples

Le règlement d'origine identique est un règlement de sécurité appliqué aux applications Web côté client (telles que les navigateurs Web) afin d'empêcher les interactions entre des ressources d'origines différentes. Bien que cette mesure de sécurité soit utile pour éviter les comportements malveillants, elle empêche également les interactions légitimes entre des origines connues. Par exemple, un script sur une page hébergée sur App Engine à l'adresse example.appspot.com peut avoir besoin d'utiliser des ressources stockées dans un bucket Cloud Storage à l'adresse example.storage.googleapis.com. Toutefois, comme il s'agit de deux origines différentes du point de vue du navigateur, celui-ci n'autorisera pas un script provenant de example.appspot.com à extraire des ressources de example.storage.googleapis.com.

Pour contourner cette limitation, le World Wide Web Consortium (W3C) a mis au point la spécification de partage des ressources entre origines multiples (CORS, Cross-Origin Resource Sharing). Cloud Storage est compatible avec cette spécification et vous permet de configurer vos buckets de sorte qu'ils l'acceptent. En reprenant l'exemple ci-dessus, vous pouvez configurer le bucket example.storage.googleapis.com afin qu'un navigateur puisse partager ses ressources avec des scripts provenant de example.appspot.com.

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

Fonctionnement du CORS

Il existe deux types de requêtes CORS, les simples et les pré-vérifiées. Une requête simple peut être lancée directement. Une requête pré-vérifiée doit envoyer au serveur une requête de "vérification préliminaire" afin d'obtenir une autorisation avant de poursuivre la requête principale. 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.

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.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.

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.

Voici une description simplifiée du CORS. Pour obtenir une description plus complète, consultez la spécification Fetch.

Compatibilité du CORS avec Cloud Storage

Cloud Storage vous permet de définir la configuration CORS au niveau du bucket seulement. Vous pouvez définir la configuration CORS d'un bucket à l'aide de l'outil de ligne de commande gsutil, de l'API XML ou de l'API JSON. Toutefois, la configuration CORS ne s'applique qu'aux requêtes d'API XML.

Différents points de terminaison Cloud Storage traitent les requêtes CORS comme suit :

  • Les points de terminaison de l'API JSON autorisent les requêtes CORS, quelle que soit la configuration CORS du bucket cible.
  • Les points de terminaison de l'API XML acceptent les requêtes CORS basées sur la configuration CORS du bucket cible.
  • Le point de terminaison de téléchargement du navigateur authentifié storage.cloud.google.com n'autorise pas les requêtes CORS. Notez que Cloud Console 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.

Éléments d'une configuration CORS

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 :

Champ Description Comportement de réponse de l'API XML Comportement de réponse de l'API JSON
Origine Spécifiez les origines que vous souhaitez autoriser pour le Cross-Origin Resource Sharing avec ce bucket Cloud Storage. Par exemple, https://origin1.example.com. Si l'origine de la requête d'un navigateur correspond à l'une des origines de votre configuration CORS, Cloud Storage renvoie Access-Control-Allow-Origin au navigateur. En l'absence de correspondance, Cloud Storage n'inclut pas Access-Control-Allow-Origin dans la réponse. Vous pouvez alors fournir une valeur générique qui autorise l'accès à toutes les origines : <Origin>*</Origin>. Cloud Storage renvoie l'en-tête Access-Control-Allow-Origin défini sur l'origine de la requête.
Méthodes

Spécifiez les méthodes HTTP que vous souhaitez autoriser pour le Cross-Origin Resource Sharing avec ce bucket Cloud Storage. La valeur est renvoyée dans l'en-tête Access-Control-Allow-Methods en réponse aux requêtes préalables qui ont abouti.

Étant donné que OPTIONS est une méthode standard utilisée par les navigateurs pour lancer des requêtes préalables, vous ne devez pas spécifier OPTIONS dans votre configuration CORS.

Cloud Storage accepte les méthodes suivantes : DELETE, GET, HEAD, POST et PUT.

Cloud Storage compare les méthodes envoyées par le navigateur dans l'en-tête Access-Control-Request-Methods à la configuration CORS du bucket. Si elles ne correspondent pas, Cloud Storage renvoie un code de réponse 200 sans en-têtes de réponse CORS.

Cloud Storage renvoie l'en-tête Access-Control-Allow-Methods défini sur les méthodes suivantes : DELETE, GET, HEAD, PATCH, POST et PUT.
En-têtes de réponse Le champ d'en-tête de réponse spécifie les en-têtes que vous souhaitez autoriser pour le Cross-Origin Resource Sharing avec ce bucket Cloud Storage. La valeur est renvoyée dans l'en-tête Access-Control-Allow-Headers en réponse à des requêtes préalables qui ont abouti. Pour les requêtes préalables, Cloud Storage compare les en-têtes envoyés depuis le navigateur dans l'en-tête Access-Control-Request-Headers à la configuration CORS du bucket. S'ils ne correspondent pas, Cloud Storage ne renvoie pas les en-têtes de réponse CORS. Cloud Storage renvoie l'ensemble d'en-têtes Access-Control-Allow-Headers égal aux valeurs spécifiées par l'en-tête Access-Control-Request-Headers.
Âge maximal en secondes (facultatif) Le champ MaxAgeSec indique le nombre de secondes pendant lesquelles le navigateur est autorisé à effectuer des requêtes avant de répéter la requête préalable. On l'appelle également le délai d'expiration du cache. Cette valeur est renvoyée dans l'en-tête Access-Control-Max-Age dans les réponses aux requêtes préalables. Par exemple, 3600 définit le délai d'expiration du cache sur 1 heure. Cloud Storage renvoie l'en-tête Access-Control-Max-Age avec le délai d'expiration du cache spécifié. Si vous omettez de renseigner ce champ, Cloud Storage renvoie la valeur par défaut 3600. Cloud Storage renvoie l'en-tête Access-Control-Max-Age avec la valeur par défaut 3600.
Informations complémentaires
Identifiants Cloud Storage n'est actuellement pas compatible avec les identifiants CORS. Cloud Storage ne renvoie jamais l'en-tête Access-Control-Allow-Credentials.

Pour les requêtes simples, si la requête CORS est approuvée et valide, l'en-tête Access-Control-Allow-Credentials est défini sur "true".

Pour les requêtes préalables, si Access-Control-Request-Method est vide, Cloud Storage définit Access-Control-Allow-Credentials sur "true" et rejette la requête avec 404 - Not Found.

En-têtes exposés L'en-tête de réponse Access-Control-Expose-Headers répertorie les noms d'en-tête exposés dans la réponse. Pour les requêtes simples, Access-Control-Expose-Headers répertorie les valeurs des en-têtes de réponse dans votre configuration CORS. Pour les requêtes simples, Access-Control-Expose-Headers renvoie les valeurs spécifiées dans Access-Control-Request-Headers si elles font partie d'une liste d'en-têtes HTTP courants.

Compatibilité du CORS côté client

La plupart des navigateurs effectuent une requête interdomaine au moyen de l'objet XMLHttpRequest. XMLHttpRequest s'occupe intégralement de l'insertion des en-têtes appropriés et de la gestion de l'interaction CORS avec le serveur. Vous n'avez pas besoin d'ajouter de nouveau code pour bénéficier de la compatibilité du CORS sur les buckets Cloud Storage.

Étapes suivantes