11. Origine, site et URL : trois notions distinctes

Comprendre le mécanisme

Une origine est définie par schéma, hôte et port selon les règles de l’URL. Deux adresses qui semblent appartenir à la même entreprise peuvent donc être d’origines différentes. La notion de site utilisée par certains contrôles de cookies ne se confond pas avec l’origine ; elle dépend notamment du domaine enregistrable et du schéma. Une même page peut enfin manipuler plusieurs URL sans leur accorder la même confiance.

Raisonner et vérifier

Écrivez les URL complètes de vos interfaces et API. Changer un sous-domaine, un port de développement ou HTTP vers HTTPS peut changer une frontière. Ne comparez pas des hôtes avec une simple recherche de sous-chaîne : une ressemblance visuelle n’établit pas l’appartenance au domaine autorisé. Pour les identifiants et redirections, utilisez les parseurs d’URL et une politique de destinations explicite.

Triplet d’origine

Une origine comporte schéma, hôte et port. Le chemin distingue des ressources, pas l’origine. Comparez schéma, hôte et port après parsing et normalisation appropriée. Le chemin d’une URL ne change pas son origine ; en revanche un port non équivalent ou un autre hôte la change.

Ports distincts

Deux ports différents peuvent donner deux origines. Le port participe à la comparaison d’origine. https://api.example.test:443 et le même hôte sur 8443 ont deux origines. Une politique qui ignore le port élargit donc la confiance au-delà de la destination explicitement prévue.

Site distinct

Site et origine ne sont pas des synonymes. Le site possède une granularité différente. Deux sous-domaines peuvent être same-site sans être same-origin. Cette différence compte lorsque vous raisonnez sur SameSite et SOP ; ne transférez pas les garanties de l’un à l’autre.

Schéma

Le schéma peut changer l’origine. Le schéma appartient au triplet. http et https ne définissent pas la même origine même avec le même nom. Une liste autorisée doit préciser explicitement les schémas attendus plutôt qu’admettre implicitement un trajet non protégé.

Parsing structuré

Une URL doit être parsée avant comparaison structurée. Des hôtes trompeurs peuvent contenir le texte attendu. Une recherche de example.test dans une chaîne peut accepter un hôte hostile ou un nom d’utilisateur trompeur. Parsez l’URL puis comparez les composants et les règles de sous-domaines effectivement admises.

Sous-domaines

Un sous-domaine n’est pas automatiquement la même origine. L’hôte exact compte pour l’origine. portal.example.test et admin.example.test ont des hôtes différents. Un contrôle d’origine peut donc les distinguer même si leur déploiement ou leurs cookies partagent certains éléments communs de leur infrastructure.

Port implicite

Un port par défaut doit être traité selon la normalisation URL. La représentation textuelle peut différer d’une URL normalisée. Pour HTTPS, un port absent et le port par défaut peuvent être normalisés de manière équivalente. Utilisez un parseur conforme au contexte au lieu de comparer naïvement les chaînes complètes.

Liste maîtrisée

Le serveur doit maîtriser sa liste d’origines admises. Une apparence textuelle n’est pas une politique exacte. La configuration serveur définit les origines admises. Ne reflétez pas une valeur reçue simplement parce qu’elle semble interne ; testez chaque règle avec un domaine voisin non autorisé.

Origine et objet

Une origine admise ne prouve pas la propriété d’un objet. Le contrôle de lecture navigateur reste distinct de l’autorisation. Une demande issue du portail autorisé peut encore viser la facture d’un tiers. Le contrôle d’origine ne remplace pas authentification et autorisation par tenant ou propriétaire sur la ressource.

Userinfo

Le nom d’utilisateur d’une URL ne définit pas son hôte. Les composants d’URL ont des positions et sens précis. Dans https://example.test@hostile.test, l’hôte est hostile.test. Une vérification textuelle peut confondre ces composants ; inspectez le résultat parsé et refusez les formes inutiles selon votre contrat.

Atelier guidé : lire, expliquer et vérifier le code

https://api.example.test:443/orders
https://api.example.test:8443/orders

Les URL ne diffèrent que par le port, mais ce composant participe à l’origine. Comparez-les après normalisation des ports par défaut, puis ajoutez une URL avec un nom d’utilisateur trompeur. L’objectif est d’expliquer une décision structurée plutôt qu’une simple recherche de sous-chaîne.

L’hôte n’est qu’une composante. Le schéma ne retire pas le port du modèle. Le triplet d’origine comprend le port. Le chemin n’efface pas cette différence.

Travail pratique : Construisez une table de six URL de laboratoire et indiquez lesquelles sont same-origin, puis étudiez séparément la portée de site des cookies.

Critères de correction : Normalisez avec un parseur, comparez les composantes pertinentes et documentez les ports implicites. Ajoutez des cas de sous-domaines, de schémas et de domaines ressemblants ; vérifiez les résultats dans le navigateur.