Résumé

  • Un projet du W3C daté du 15 février 2007 proposait que le propriétaire d’une ressource assouplisse la frontière de lecture entre sites. Le projet du 17 mars 2009 portait déjà le nom Cross-Origin Resource Sharing et précisait le dialogue entre origine, réponse et navigateur.
  • Dans la recommandation du 16 janvier 2014, le serveur peut désigner les origines autorisées à lire sa réponse. Certaines méthodes ou en-têtes déclenchent d’abord une requête OPTIONS ; le simple fait qu’une requête atteigne un serveur ne donne pas à un script le droit de lire sa réponse.

La scène est banale : un tableau de bord veut afficher des données hébergées ailleurs. Le script connaît l’adresse, le serveur voisin possède les chiffres, et pourtant le navigateur hésite. Il garde une frontière entre les origines pour éviter que chaque page ouverte ne puisse lire à loisir les réponses destinées à une autre. Les habitants de l’immeuble peuvent se parler ; ils n’ont pas automatiquement les clés des boîtes aux lettres.

Dans le projet du W3C du 15 février 2007, Enabling Read Access for Web Resources, l’auteur d’une ressource pouvait annoncer des exceptions au verrou de lecture, par en-tête HTTP ou instruction XML. Le texte tâtonnait encore entre plusieurs formes de motifs d’hôtes. Son idée décisive était ailleurs : l’autorisation de lire venait de celui qui publie la ressource, et le navigateur devait l’interpréter. Le projet CORS du 17 mars 2009 a donné à cette négociation des en-têtes plus reconnaissables, notamment l’origine de la page demandeuse et la réponse d’autorisation.

La recommandation CORS du 16 janvier 2014 formule le billet d’entrée : la ressource répond avec Access-Control-Allow-Origin, éventuellement pour l’origine précise indiquée dans la demande. Le navigateur confronte cette réponse à l’origine du script appelant avant de lui livrer le contenu. Pour une ressource publiquement partageable, le caractère * ouvre plus largement la lecture lorsque les identifiants ne sont pas inclus. Dès que la requête transporte des identifiants, il faut une origine qui corresponde et Access-Control-Allow-Credentials: true. Une invitation nominative et une porte ouverte ne sont pas la même politique.

Il arrive que le navigateur sonne avant d’envoyer la vraie requête. Si la méthode ou des en-têtes choisis par le script sortent du jeu simple, la requête préliminaire OPTIONS interroge le serveur sur les méthodes et en-têtes acceptés. Le navigateur examine la réponse avant la requête principale et peut mémoriser temporairement ce résultat. Le fameux « préflight » a donc des conditions ; il n’accompagne pas chaque visite du voisinage.

La subtilité qui épargne bien des contresens est plus terre à terre. Une requête simple peut atteindre le serveur même si le script n’aura finalement pas accès à sa réponse. Le serveur peut avoir traité une action ; il doit lui-même décider si cette action était autorisée. La section de sécurité du texte de 2014 distingue expressément l’autorisation de la requête et de ses effets de l’autorisation d’accès à la représentation retournée. Coller un en-tête CORS sur une opération sensible ne fait pas le travail de l’autorisation côté serveur.

Le concierge du navigateur contrôle le courrier remis au visiteur, pas toute la comptabilité de l’immeuble.

L’historique de publication du W3C replace ces étapes dans le temps : premières esquisses en 2007, annonce de la recommandation en 2014, puis retrait formel de ce document en 2020. Cette chronologie raconte une solution précise à une friction du Web : la ressource peut dire « cette page peut lire ma réponse », et le navigateur peut faire respecter ce choix. Les données traversent la rue sans que la clé de l’appartement change de main.