Summary

  • La révision du 27 octobre d’un projet du groupe CDNI décrit un échec précis : une origine autorisée reçoit un en-tête CORS *, puis un cache partagé peut le réutiliser pour une origine exclue si la réponse ne varie pas correctement.
  • Le texte précise aussi que le contrôle CORS se joue dans le navigateur : le CDN aval peut toujours servir la ressource publique, même sans les en-têtes qui en permettraient l’exposition à un script.

À l’entrée, la liste des invités est appliquée à la lettre. Une personne passe, reçoit un bracelet et confie son manteau au vestiaire. Le vestiaire recopie le bracelet pour la personne suivante, absente de la liste. La vérification initiale était correcte ; le souvenir de cette vérification s’est égaré plus loin. La version -13 du projet CDNI met cette scène en termes de CDN aval, d’origine web et de cache partagé.

Le CDN amont transmet une politique MI.CrossoriginPolicy au CDN aval par l’interface de métadonnées de RFC 8006. Elle peut contenir une liste d’origines permises. À la périphérie, le CDN compare l’en-tête Origin de la demande à cette liste. Si wildcard-return est activé, une origine qui correspond peut recevoir Access-Control-Allow-Origin: *. Celle qui ne correspond pas ne reçoit aucun en-tête CORS de ce type.

Le piège tient à ce que le caractère * ne dit pas quelle origine a réussi la vérification. Quand un cache partagé réutilise pour une autre origine une réponse munie de cet en-tête, le navigateur exclu peut voir un bracelet qui n’était destiné qu’à la première demande. La nouvelle section opérationnelle du projet appelle explicitement cette possibilité. Elle s’articule avec deux obligations du CDN aval : générer les en-têtes CORS pour chaque réponse au lieu de les incorporer à la représentation mise en cache, et faire figurer dans Vary les en-têtes de demande qui font varier le résultat.

Le texte précédent, -12, définissait déjà les objets de configuration. La révision du 27 octobre précise leur portée. Les en-têtes CORS demandent au navigateur conforme s’il peut exposer la réponse à un script exécuté sous une autre origine. Sans ces en-têtes, le CDN aval sert encore la ressource publiquement accessible ; le navigateur refuse l’exposition transversale au script. Les demandes dont le mode de crédentiels est include restent hors du dispositif décrit, car leur combinaison avec l’authentification réclame autre chose qu’une simple configuration CORS.

Le calendrier de déploiement compte autant que la liste. Si le CDN amont ouvre une ressource avant que la politique n’atteigne la périphérie, le CDN aval la sert sans en-têtes CORS jusqu’à la prise d’effet de la configuration. Le nouveau passage opérationnel invite à consulter la configuration réellement présente grâce à RFC 8006, puis à la confronter au comportement observé. Aucun mécanisme de surveillance supplémentaire n’est créé : il faut donc relier soi-même l’instruction envoyée, l’instruction reçue et la réponse délivrée.

Le Datatracker de l’IETF place -13 dans l’évaluation IESG comme projet du groupe CDNI. Entre l’amont, l’aval et le cache, chacun peut avoir une liste impeccable. Le lecteur, lui, reçoit le bracelet sorti du dernier guichet.