Utilisation d’Azure CDN avec CORS

Important

Azure CDN Standard de Microsoft (classique) sera mis hors service le 30 septembre 2027. Pour éviter toute interruption de service, il est important de migrer vos profils du niveau Azure CDN Standard de Microsoft (classique) vers le niveau Azure Front Door Standard ou Premium au plus tard le 30 septembre 2027. Pour découvrir plus d’informations, consultez Mise hors service d’Azure CDN Standard de Microsoft (classique).

Azure CDN d’Edgio sera mis hors service le 15 janvier 2025. Pour éviter toute interruption de service, vous devez migrer votre charge de travail vers Azure Front Door avant cette date. Pour plus d’informations, consultez FAQ sur la mise hors service d’Azure CDN d’Edgio.

Présentation de CORS

CORS (Cross-Origin Resource Sharing) est une fonctionnalité HTTP qui permet à une application web exécutée dans un domaine d’accéder aux ressources d’un autre domaine. Pour réduire le risque d’attaques de script entre sites, tous les navigateurs web modernes implémentent une restriction de sécurité appelée stratégie de même origine. Cette restriction empêche une page web d’appeler des API dans un autre domaine. CORS permet à une origine (le domaine d’origine) d’appeler des API dans un autre domaine de façon sécurisée.

Fonctionnement

Il existe deux types de demandes CORS : les demandes simples et les demandes complexes.

Pour les demandes simples :

1. Le navigateur envoie la demande CORS avec un en-tête de requête HTTP Origin supplémentaire. La valeur de l’en-tête demande est l’origine qui a servi la page mère, définie comme la combinaison du protocole, du domaine et du port. Quand une page de HTTPS://www.contoso.com tente d’accéder aux données d’un utilisateur dans l’origine fabrikam.com, l’en-tête de la requête suivant est envoyé à fabrikam.com :

   Origin: https://www.contoso.com

2. Le serveur peut répondre avec l’un des en-têtes suivants :

   • Un en-tête Access-Control-Allow-Origin indiquant le site d’origine autorisé. Par exemple :

     Access-Control-Allow-Origin: https://www.contoso.com

   • Un code d’erreur HTTP comme 403 si le serveur n’autorise pas la demande d’origine croisée après avoir vérifié l’en-tête d’origine.

   • Un en-tête Access-Control-Allow-Origin avec un caractère générique qui autorise toutes les origines :

     Access-Control-Allow-Origin: *

Pour les demandes complexes :

Une demande complexe est une demande CORS où le navigateur est nécessaire pour envoyer une demande préliminaire (c’est-à-dire une sonde préliminaire) avant d’envoyer la demande CORS. La demande préliminaire demande l’autorisation au serveur si la demande CORS d’origine peut se poursuivre et est une demande OPTIONS transmise à la même URL.

Conseil

Pour plus d’informations sur les flux CORS et les pièges les plus courants, consultez le Authoritative guide to CORS (Cross-Origin Resource Sharing) for REST APIs (Guide de référence sur CORS (Cross-Origin Resource Sharing) pour les API REST).

Scénarios avec caractère générique ou à origine unique

CORS sur Azure CDN fonctionne automatiquement sans configuration supplémentaire quand l’en-tête Access-Control-Allow-Origin est défini sur le caractère générique (*) ou une seule origine. Le CDN met en cache la première réponse, et les demandes suivantes utilisent le même en-tête.

Si les demandes ont déjà été envoyées au CDN avant que CORS ne soit défini sur votre origine, vous devez vider le contenu de votre point de terminaison pour recharger le contenu avec l’en-tête Access-Control-Allow-Origin.

Scénarios avec plusieurs origines

Si une liste d’origines spécifique doit être autorisée pour CORS, les choses se compliquent un peu plus. Le problème se produit quand le CDN met en cache l’en-tête Access-Control-Allow-Origin pour la première origine CORS. Quand une autre origine CORS envoie une demande ultérieure, le CDN sert l’en-tête Access-Control-Allow-Origin mis en cache, qui ne correspond pas. Il existe plusieurs façons de résoudre ce problème.

Profils CDN Azure standard

Sur Azure CDN standard de Microsoft, vous pouvez créer une règle dans le moteur de règles standard pour vérifier l’en-tête Origin sur la demande. S’il s’agit d’une origine valide, votre règle définit l’en-tête Access-Control-Allow-Origin avec la valeur souhaitée. Dans ce cas, l’en-tête Access-Control-Allow-Origin issu du serveur d’origine du fichier est ignoré et le moteur de règles du CDN gère entièrement les origines CORS autorisées.

Conseil

Vous pouvez ajouter des actions supplémentaires à votre règle pour modifier des en-têtes de réponse supplémentaires, par exemple Access-Control-Allow-Methods.

Azure CDN Premium fourni par Edgio

Avec le moteur de règles Edgio Premium, vous devez créer une règle pour vérifier l’en-tête Origine dans la demande. S’il s’agit d’une origine valide, votre règle définit l’en-tête Access-Control-Allow-Origin avec l’origine fournie dans la demande. Si l’origine spécifiée dans l’en-tête Origin n’est pas autorisée, votre règle doit omettre l’en-tête Access-Control-Allow-Origin, ce qui amène le navigateur à rejeter la demande.

Vous pouvez résoudre ce problème de deux façons avec le moteur de règles Premium. Dans les deux cas, l’en-tête Access-Control-Allow-Origin issu du serveur d’origine du fichier est ignoré et le moteur de règles du CDN gère entièrement les origines CORS autorisées.

Une expression régulière avec toutes les origines valides

Dans ce cas, vous créez une expression régulière qui comprend toutes les origines que vous souhaitez autoriser :

https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.com)$

Conseil

Azure CDN Premium d’Edgio utilise PCRE (Perl Compatible Regular Expressions) comme moteur pour les expressions régulières. Vous pouvez utiliser un outil tel que Regular Expressions 101 pour valider votre expression régulière. Notez que le caractère « / » est valide dans les expressions régulières et n’a pas besoin d’être échappé ; toutefois, échapper ce caractère est une pratique recommandée et attendue par certains validateurs d’expression régulière.

Si l’expression régulière correspond, votre règle remplace l’en-tête Access-Control-Allow-Origin (le cas échéant) de l’origine par l’origine qui a envoyé la demande. Vous pouvez également ajouter des en-têtes CORS supplémentaires, comme Access-Control-Allow-Methods.

Règle d’en-tête de demande pour chaque origine

Au lieu de recourir à des expressions régulières, vous pouvez créer une règle pour chaque origine à autoriser en utilisant la condition de correspondance Request Header Wildcard (Caractère générique de l’en-tête de demande). Comme dans le cas de la méthode des expressions régulières, seul le moteur de règles définit les en-têtes CORS.

Conseil

Dans l’exemple, l’utilisation du caractère générique * indique au moteur de règles de faire correspondre HTTP et HTTPS.