Utilisation d’Azure CDN avec CORS
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 :
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 de demande est l’origine qui a servi la page parente, 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 demande suivant est envoyé à fabrikam.com :
Origin: https://www.contoso.comLe 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.comUn 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 correspondanceRequest Header Wildcard (Caractère générique pour l’en-tête de la 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.