Un fichier Docker Compose ? Votre projet est en ligne en quelques secondes, en une seule commande sur cdn.com.tr. Voir comment App créée avec l'IA ? Du dossier au live en une commande — sans git ni registry : cdnctl deploy. Voir comment Votre code sur GitHub ? Chaque push se déploie tout seul sur cdn.com.tr — connectez votre dépôt. Voir comment

Aide CDN.com.tr

En-têtes CORS sur l'edge

Ajoutez Access-Control-Allow-Origin et les autres en-têtes CORS aux réponses d'une règle de diffusion, laissez votre origine répondre aux requêtes OPTIONS de preflight, et autorisez dans le WAF les méthodes qu'utilise votre API.

Cache, sécurité, WAF et purge

En-têtes CORS sur l'edge

Ajoutez Access-Control-Allow-Origin et les autres en-têtes CORS aux réponses d'une règle de diffusion, laissez votre origine répondre aux requêtes OPTIONS de preflight, et autorisez dans le WAF les méthodes qu'utilise votre API.

Guides associés

Comment CORS fonctionne dans le navigateur, comment lire une requête refusée par l'edge, et ce que votre origine reçoit d'autre de l'edge.

Contexte

Qu'est-ce que CORS ? La règle du navigateur derrière chaque erreur cross-origin

Requêtes simples, preflights et identifiants, avec des tests curl.

Lire le guide
Un 403 de l'edge

Lire les journaux WAF

Retrouvez une requête refusée par heure ou par Reference ID et voyez quelle règle l'a bloquée.

Ouvrir le sujet
Votre origine

Connexion à l'origine : l'IP réelle du visiteur, verrouiller votre origine, WebSocket et délais d'attente

Les en-têtes envoyés à votre origine, et les méthodes WAF dont une API a besoin.

Ouvrir le sujet

Chemin dans le panneau

  1. Panneau de gestion
  2. Règles de diffusion
  3. Règles
  4. Modifier
  5. En-têtes
  6. Ajouter des en-têtes de réponse

Prerequis

  • Une règle de diffusion qui sert les chemins que demande l'autre site.
  • L'origine exacte du site demandeur, comme https://app.example.com, ou * pour des fichiers que tout le monde peut charger.
  • Pour les appels d'API qui envoient un preflight : votre origine répond à OPTIONS sur ces chemins par 200 ou 204.
  • Le rôle propriétaire ou éditeur : les lecteurs voient les règles, mais ne peuvent pas les modifier.

Modele de decision

Fichiers publics ou API ?

Ce qu'envoie le navigateur détermine où le travail se fait.

  • Polices, images et JSON public chargés par un simple GET : pas de preflight, et Access-Control-Allow-Origin dans la règle suffit. Tant que l'optimisation des images de tout le compte est activée, les fichiers .jpg, .jpeg et .png prennent les en-têtes de réponse de la règle la plus ancienne du domaine, pas ceux de la règle de leur chemin.
  • Appels d'API avec corps JSON, en-têtes personnalisés ou PUT, PATCH, DELETE : le navigateur envoie d'abord un preflight ; votre origine y répond, et la règle peut ajouter les en-têtes CORS à cette réponse.
  • Requêtes avec des cookies ou d'autres identifiants : une seule origine nommée, pas *, plus Access-Control-Allow-Credentials true.

Chaque en-tête depuis l'edge ou depuis votre origine ?

Choisissez une seule source par en-tête.

  • Edge (la règle) : une valeur fixe sur chaque réponse 2xx et 3xx, y compris celles servies depuis le cache, et aussi sur les réponses 4xx et 5xx de votre origine si la ligne se termine par always.
  • Origine : une valeur qui dépend du site demandeur, envoyée avec Vary: Origin.
  • Envoyé par les deux : cochez-le sous Supprimer des en-têtes, afin que seule la valeur de la règle parte.

Guide etape par etape

1

Ajoutez les en-têtes à la règle

Exemple pour une API sous /api/ qu'appelle une application web. Écrivez un en-tête par ligne ; une valeur contenant des espaces se met entre guillemets doubles.

  • Ouvrez Règles de diffusion → Règles et cliquez sur Modifier sur la règle de /api/.
  • Sous Alors → En-têtes, écrivez dans Ajouter des en-têtes de réponse, chacun sur sa propre ligne : Access-Control-Allow-Origin https://app.example.com, Access-Control-Allow-Methods "GET, POST, PUT, OPTIONS", Access-Control-Allow-Headers "Content-Type, Authorization" et Access-Control-Max-Age 600.
  • Sous Supprimer des en-têtes, cochez ceux de ces noms que votre origine envoie aussi.
  • Cliquez sur Enregistrer la règle.

Resultat attendu: La règle affiche une pastille comme +4 en-têtes de réponse, et la page affiche En ligne une fois que l'edge la sert.

2

Autorisez les méthodes de l'API dans le WAF

Nécessaire tant que le WAF de tout le site est activé et que l'API utilise d'autres méthodes que GET, HEAD, POST et OPTIONS.

  • Dans la barre latérale, ouvrez WAF Logs sous Protection.
  • Sous Méthodes HTTP autorisées, cochez PUT, PATCH ou DELETE selon les besoins de votre API, laissez OPTIONS coché et cliquez sur Save.

Resultat attendu: Le panneau confirme l'enregistrement, et la modification se propage en 1-2 minutes.

3

Vérifiez une requête simple et un preflight

curl n'applique pas CORS : il montre donc exactement ce que répond l'edge.

  • Demandez l'endpoint avec un en-tête Origin.
  • Envoyez le preflight qu'enverrait un navigateur : OPTIONS avec Origin, Access-Control-Request-Method et Access-Control-Request-Headers.

Resultat attendu: La requête simple porte un seul access-control-allow-origin. Le preflight répond 200 ou 204 avec l'origine, les méthodes et les en-têtes autorisés.

cdnctl equivalent 
curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)'
curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)'

Verification

  • curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)' → 2xx et exactement un access-control-allow-origin: https://app.example.com
  • curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)' → 200 ou 204 avec access-control-allow-origin, access-control-allow-methods et access-control-allow-headers
  • Un 403 avec x-mt-blocked-by: cdn-edge-security sur une requête → l'edge l'a refusée (le WAF, ou un blocage par IP, pays, réseau ou hotlink) ; vérifiez Méthodes HTTP autorisées et les journaux WAF

Cas d'usage

Une application web sur app.example.com charge des polices, du JSON ou des réponses d'API depuis www.example.com, et le navigateur les bloque avec une erreur CORS.

Workflow rapide

  1. Ouvrez les Règles de diffusion, allez dans l'onglet Règles et cliquez sur Modifier sur la règle qui sert les chemins que demande l'autre site, ou sur Ajouter une règle pour un nouveau chemin.
  2. Sous Alors, ouvrez En-têtes et écrivez un en-tête par ligne dans Ajouter des en-têtes de réponse sous la forme Nom-En-tête valeur, sans deux-points, par exemple Access-Control-Allow-Origin https://app.example.com. Une valeur contenant des espaces se met entre guillemets doubles.
  3. Si votre origine envoie déjà un en-tête Access-Control-* pour ces chemins, cochez le même nom sous Supprimer des en-têtes, afin que le navigateur reçoive une seule valeur.
  4. Cliquez sur Enregistrer la règle (Créer la règle pour une nouvelle règle) et attendez que la page affiche En ligne.
  5. Si votre API utilise PUT, PATCH ou DELETE et que le WAF de tout le site est activé, cochez-les sous Méthodes HTTP autorisées sur la page Security.
  6. Vérifiez une requête simple et un preflight avec curl.

Verifications

  • Les en-têtes de la règle sont ajoutés aux réponses réussies et de redirection (2xx et 3xx), y compris celles servies depuis le cache, dès la publication de la règle. Une ligne qui se termine par always est aussi ajoutée aux réponses 4xx et 5xx de votre origine.
  • Les requêtes OPTIONS de preflight vont à votre origine et ne sont jamais mises en cache. Lorsque votre origine répond à un preflight par 200 ou 204, les en-têtes de la règle sont ajoutés à cette réponse ; un preflight qui reçoit 401, 404 ou 405 arrive au navigateur sans eux, sauf si la ligne se termine par always. Sur une règle avec Protection par mot de passe ou une Liste d'IP autorisées, l'edge répond lui-même par 401 ou 403 à un preflight qu'il ne laisse pas passer.
  • Un seul Access-Control-Allow-Origin arrive au navigateur : avec deux valeurs, le navigateur rejette la réponse.
  • Si votre origine fait varier Access-Control-Allow-Origin selon le site demandeur, elle doit aussi envoyer Vary: Origin. L'edge garde ces variantes séparées tant que Garder une seule copie en cache quel que soit l'en-tête Vary est désactivé sur la règle.
  • Laissez Access-Control-Request-Method et Access-Control-Request-Headers décochés sous Supprimer des en-têtes : les noms cochés à cet endroit sont aussi retirés des requêtes envoyées à votre origine, et votre origine lit ces deux en-têtes pour répondre à un preflight.
  • Avec le WAF de tout le site activé, GET, HEAD, POST et OPTIONS sont autorisés par défaut. Une requête dont la méthode ne figure pas dans la liste reçoit un 403 sans en-têtes CORS et avec X-MT-Blocked-By: cdn-edge-security, que le navigateur signale comme une erreur CORS.
  • Tant que l'optimisation des images de tout le compte est activée, les fichiers .jpg, .jpeg et .png reçoivent les en-têtes de réponse de la règle la plus ancienne du domaine, pas ceux de la règle de leur chemin : placez l'en-tête CORS de ces images sur cette règle, avec un Access-Control-Allow-Origin fixe. Lorsque cette règle la plus ancienne est la règle de vérification de certificat, ils ne reçoivent aucun en-tête de règle.

Questions frequentes

L'edge répond-il lui-même aux requêtes de preflight ?

L'edge transmet les requêtes OPTIONS à votre origine et ne les met jamais en cache : votre origine doit donc répondre au preflight par 200 ou 204. Les en-têtes de réponse de la règle sont ajoutés à cette réponse : les en-têtes CORS peuvent venir de la règle, et votre origine n'a qu'à accepter OPTIONS. Exception : sur une règle avec Protection par mot de passe ou une Liste d'IP autorisées, l'edge répond lui-même par 401 ou 403 à un preflight qu'il ne laisse pas passer.

Une règle peut-elle autoriser plusieurs sites ?

Une règle ajoute la même valeur à chaque réponse : * ou une origine comme https://app.example.com. Pour autoriser plusieurs origines, laissez votre application envoyer l'origine correspondante avec Vary: Origin, et ne mettez pas Access-Control-Allow-Origin dans la règle. Les requêtes avec des cookies ou d'autres identifiants ont besoin d'une origine nommée, pas de *.

Le navigateur signale toujours une erreur CORS. Que dois-je vérifier ?

Commencez par le statut de la requête en échec dans le panneau réseau du navigateur. Un 403 avec X-MT-Blocked-By: cdn-edge-security vient de l'edge : recherchez-le dans les journaux WAF, et si sa méthode manque, ajoutez-la sous Méthodes HTTP autorisées. Par défaut, tout autre 4xx ou 5xx arrive sans les en-têtes de la règle : corrigez d'abord cette réponse. Une ligne qui se termine par always, comme Access-Control-Allow-Origin https://app.example.com always, est aussi ajoutée aux réponses 4xx et 5xx de votre origine. Vérifiez ensuite qu'un seul Access-Control-Allow-Origin arrive et qu'il correspond au site demandeur, schéma compris.

Mon API utilise PUT, PATCH ou DELETE. Que dois-je changer ?

Tant que le WAF de tout le site est activé, ouvrez la page Security, cochez les méthodes sous Méthodes HTTP autorisées et cliquez sur Save ; la modification se propage en 1-2 minutes. Méthodes de requête autorisées, dans l'onglet Sécurité des Règles de diffusion, ouvre la même carte. Laissez OPTIONS coché : les navigateurs l'envoient pour les preflights.