La politique de même origine (Same-Origin Policy) est un mécanisme de sécurité essentiel des navigateurs qui limite la manière dont un document ou un script chargé à partir d'une origine peut interagir avec des ressources provenant d'autres origines. Elle permet d'empêcher les sites malveillants de lire les données sensibles d'autres sites web. La politique considère que deux URL ont la même origine si elles partagent le même protocole, le même hôte et le même numéro de port.
La politique de même origine (SOP, pour same-origin policy) est la règle d'isolation fondamentale du navigateur. Elle considère deux URL comme ayant la même origine uniquement lorsqu'elles partagent le même schéma, le même hôte et le même port ; ainsi, https://shop.example:443 et http://shop.example ou https://api.example sont des origines différentes. Sous la SOP, un script exécuté sur une origine peut charger certaines ressources cross-origin (images, scripts, feuilles de style) mais ne peut pas lire les réponses, inspecter le DOM d'une autre origine, ni accéder à ses cookies, à son localStorage et à son IndexedDB. Cette politique est appliquée par le navigateur lui-même, et non par le serveur, et s'applique par origine plutôt que par page. Sans elle, n'importe quel onglet ouvert pourrait lire en silence votre messagerie web ou votre session bancaire dans un autre onglet.
La SOP est ce qui empêche un site malveillant de manipuler vos sessions connectées ailleurs. Comme les navigateurs joignent automatiquement vos cookies aux requêtes, une page pourrait sinon émettre un fetch vers votre banque et lire le solde du compte dans la réponse. La SOP bloque cette lecture, ce qui limite la falsification de requête intersites et le vol de données cross-origin. Elle n'est pas absolue : elle régit la lecture, pas l'envoi, si bien que des requêtes modifiant l'état peuvent toujours être déclenchées, et un CORS mal configuré, des gestionnaires postMessage trop permissifs ou une attaque XSS s'exécutant au sein de l'origine de confiance la contournent tous. La SOP est une frontière entre origines, pas une défense contre du code qui s'exécute déjà au sein de votre propre origine.
Considérez la SOP comme un comportement par défaut à préserver, pas comme un obstacle à contourner. Lorsque vous avez réellement besoin d'un accès cross-origin, utilisez CORS avec une liste d'autorisation stricte plutôt que de refléter des origines arbitraires ou d'utiliser un caractère générique sur des points de terminaison avec identifiants. Validez l'origine de chaque événement postMessage avant d'agir en conséquence, définissez soigneusement la portée des cookies et gardez les jetons d'authentification hors du localStorage, où tout script de même origine peut les lire. La faille la plus difficile à combler est un script qui s'exécute au sein de votre propre origine, puisque la SOP lui accorde une confiance totale. Surveiller ce que vos scripts tiers font réellement à l'exécution, ce qui constitue le cœur de la sécurité côté client, est la façon de détecter tout abus de cette confiance héritée.
Non. La SOP restreint la lecture des réponses cross-origin, pas l'émission des requêtes. Une page peut toujours envoyer une requête vers une autre origine, et le navigateur y joint vos cookies. La SOP empêche simplement la page émettrice de lire ce qui revient, c'est pourquoi les défenses contre le CSRF comme les cookies SameSite et les jetons restent nécessaires.
Non. app.example.com et api.example.com sont des origines différentes parce que l'hôte diffère, la SOP les isole donc par défaut. Des sites liés peuvent assouplir certaines interactions via des en-têtes CORS ou, dans de rares cas hérités, via document.domain, mais les navigateurs restreignent de plus en plus ces échappatoires au profit d'un CORS explicite.
We answer client-side security questions every day. Bring yours.