La politique de même origine (Same-Origin Policy) : ce qu'est une origine et ce qu'elle isole

Ce que c'est

La RFC 6454 définit une origine comme le triplet schéma, hôte et port ; MDN l'appelle le « triplet schéma/hôte/port ». https://example.com, https://example.com:8443, http://example.com et https://app.example.com sont quatre origines différentes ; le chemin et la requête n'entrent pas en jeu. La politique de même origine est la règle du navigateur régissant les interactions entre origines. MDN les classe en trois groupes : les écritures cross-origin (liens, redirections, soumissions de formulaire) sont typiquement autorisées ; l'intégration cross-origin (img, script, iframe, feuilles de style, polices) est typiquement autorisée, mais le contenu intégré est opaque pour le script ; les lectures cross-origin (le DOM d'une autre fenêtre ou d'un autre cadre, le corps d'une réponse fetch, le stockage d'une autre origine) sont typiquement interdites. CORS est l'opt-in côté serveur qui assouplit les lectures. Les cookies suivent leur propre portée : la RFC 6265 note qu'ils n'assurent pas d'isolation par port.

Pourquoi c'est important

La politique est la raison pour laquelle une page hostile ne peut pas charger votre banque dans un cadre caché et lire le solde, et aussi la raison pour laquelle un front-end légitime sur une autre origine ne peut pas lire les réponses de votre API tant que l'API ne l'y autorise pas. Deux catégories d'erreur découlent d'une mauvaise compréhension de cela : ouvrir CORS à toute origine avec des identifiants parce que « le navigateur l'a bloqué », et supposer que la politique empêche la falsification de requête intersite (CSRF), ce qu'elle ne fait pas, puisque les écritures sont autorisées.

Comment l'appliquer

• Préférer une seule origine pour l'application et l'API (un reverse proxy sous un seul hôte) ; cela supprime la configuration CORS et garde les cookies simples.
• Traiter les sous-domaines comme étrangers pour le script et le stockage ; un cookie avec Domain=example.com les couvre tous, ce qui compte lorsqu'un sous-domaine héberge du contenu utilisateur.
• Ne jamais utiliser document.domain pour assouplir le contrôle ; MDN le marque comme obsolète car cela compromet l'isolation.
• Échanger des données avec des cadres tiers intégrés via postMessage avec une origine cible explicite, et vérifier event.origin à la réception.
• Protéger les points de terminaison qui modifient l'état avec des jetons CSRF ou des cookies SameSite ; la politique ne le fera pas.
• Contrôler qui peut vous mettre dans un cadre avec la directive CSP frame-ancestors, et qui peut charger vos sous-ressources avec Cross-Origin-Resource-Policy.

Pièges

Pendant le développement, http://localhost:3000 et http://localhost:5173 sont des origines distinctes, ce qui explique pourquoi les serveurs de développement proposent des proxys. Un iframe d'une autre origine ne peut pas être inspecté par le parent, mais le parent peut le faire naviguer. Une réponse récupérée avec mode: "no-cors" est opaque : la page qui l'a demandée ne peut lire ni son statut ni son corps.