Résumé

  • Le projet Origin de janvier 2009 proposait d'indiquer au serveur le contexte à l'origine d'une requête, notamment pour examiner les tentatives de requêtes intersites. Le RFC 6454, publié en décembre 2011, a fixé la notion plus large d'origine du Web.
  • Le navigateur compare le protocole, l'hôte et le port. Le chemin ne compte pas. Une page déposée par un inconnu sous la même origine peut ainsi partager les privilèges de l'application dans le navigateur.

Deux pages, une seule frontière

Un service peut ranger son espace personnel sous /compte et les contributions de ses lecteurs sous /depot. Sur le serveur, les deux répertoires ont peut-être des règles différentes. Dans le navigateur, des URL ayant le même protocole, le même hôte et le même port appartiennent à la même origine. Le mot « dépôt » inscrit dans le chemin n'est pas un garde-frontière.

Le RFC 6454 de décembre 2011 a mis de l'ordre dans une pratique que les navigateurs avaient élaborée au fil du temps. Il ne raconte pas la naissance soudaine d'une politique. Il définit l'unité que le navigateur utilise pour répartir confiance et accès entre les pages. Traiter chaque URL comme un territoire autonome aurait obligé les applications composées de nombreuses ressources à négocier sans cesse leurs échanges. Une origine commune permet à ces ressources de travailler ensemble.

La contrepartie tient dans ce que l'on rassemble. Le RFC prend l'exemple du contenu fourni par les utilisateurs : si un service le renvoie comme du HTML actif sur son origine principale, ce contenu peut agir dans le contexte de cette origine. Le type de réponse et le lieu d'hébergement deviennent des décisions de sécurité. Le serveur peut encore refuser une opération à une personne dépourvue de droits ; le navigateur, lui, ne réduit pas les droits d'une page parce que son chemin paraît moins noble.

Le détail qui change la ligne

Le port mérite sa place dans le triplet. Une page HTTP sur example.com et un autre chemin sur ce même hôte avec le port 80 indiqué ont la même origine : 80 est le port par défaut de HTTP. Changer de port change l'origine. Passer de HTTP à HTTPS la change aussi, même si le nom d'hôte ne bouge pas. Le RFC explique pourquoi : une page reçue sans protection contre un attaquant du réseau ne doit pas hériter de la confiance accordée à la version HTTPS.

Le chemin, lui, reste à l'intérieur. Cette simplicité est utile au quotidien : des pages, scripts et documents du même service coopèrent. Elle devient coûteuse lorsque l'exploitant laisse entrer du HTML étranger sous ce même triplet. Le navigateur applique sa règle à l'adresse effective ; il ne lit pas l'organigramme du site ni la promesse affichée sur la page d'accueil.

Le premier projet Origin de janvier 2009 partait d'une autre scène : une requête arrive, et le serveur veut connaître le contexte qui l'a provoquée. Le projet proposait un en-tête Origin utilisable dans la défense contre les requêtes forgées depuis un autre site. C'était un Internet-Draft, pas une norme adoptée. Le RFC 6454 a ensuite décrit l'origine comme une pièce du modèle du navigateur, puis son expression dans un en-tête. Une origine sans triplet ordinaire est sérialisée par null; le texte prévoit aussi cette valeur pour un contexte jugé sensible à la vie privée.

La Recommandation CORS de 2014 a utilisé cette identité lorsque le site destinataire décide qui peut lire sa réponse. Elle distingue expressément cette lecture de l'autorisation d'exécuter une action. L'histoire propre de CORS appartient à une autre enquête. Ici, le choix déterminant précède l'invitation : à qui le navigateur a-t-il déjà donné la même pièce ?

Le RFC a rendu cette décision visible. Le navigateur compte le port ; l'éditeur du site doit compter les pages qu'il place derrière lui.