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.

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 cherchant à partager les ressources de l'autre domaine, par exemple, Origin:http://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. Le serveur 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.

Ceci est une description très simplifiée du CORS. Pour obtenir une description plus complète, lisez la spécification de partage des ressources entre origines multiples.

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.

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.

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