--- title: Same-origin policy slug: Web/Security/Same-origin_policy translation_of: Web/Security/Same-origin_policy original_slug: Web/Security/Same_origin_policy_for_JavaScript ---
La same-origin policy restreint la manière dont un document ou un script chargé depuis une origine peut interagir avec une autre ressource chargée depuis une autre origine.
Deux pages ont la même origine si le protocole, le port (si spécifié) et l'hôte sont les mêmes pour les deux pages. Le tableau suivant présente des comparaisons d'origines pour l'URL http://store.company.com/dir/page.html
:
URL | Résultat | Motif |
---|---|---|
http://store.company.com/dir2/other.html |
Succès | |
http://store.company.com/dir/inner/another.html |
Succès | |
https://store.company.com/secure.html |
Échec | Protocoles différents |
http://store.company.com:81/dir/etc.html |
Échec | Ports différents |
http://news.company.com/dir/other.html |
Échec | Hôtes différents |
Voir aussi origin definition for file:
URLs.
Les cookies utilisent une définition de l'origine différente de celle qui vient d'être définie.
Une page peut changer son origine dans une certaine mesure. Un script peut définir la valeur de document.domain
vers un suffixe du domaine courant. S'il procéde ainsi, le domaine le plus court sera utilisé pour les prochaines vérifications d'origines. Par exemple, un script dans la page http://store.company.com/dir/other.html
exécute le code suivant :
document.domain = "company.com";
Après l'exécution de ce code, la page passerait le test d'origine avec http://company.com/dir/page.html
. Ceci-dit, il ne serait pas possible de définir document.domain
à othercompany.com
.
Le numéro de port est stocké par le navigateur séparément. Tout appel aux setter, y compris document.domain = document.domain
entraine l'effacement du port par la valeur null
. Une page située sur company.com:8080
ne peut donc pas communiquer avec une autre située sur company.com
en ne définissant que document.domain = "company.com"
dans la première page. Ceci doit être fait dans les deux pages, ainsi les ports seront à null
pour les deux.
La same-origin policy contrôle les interactions entre deux origines différentes, quand vous utilisez XMLHttpRequest
par exemple. Ces interactions sont généralement rangées dans trois catégories :
Voici quelques exemples de ressources qui peuvent être embarqués malgré leur origine incompatible avec la same-origin policy :
<script src="..."></script>
. Les messages d'erreur de syntaxe ne sont disponibles que pour les scripts ayant la même origine. <link rel="stylesheet" href="...">
. Étant donnée la souplesse des règles de syntaxe du CSS, les CSS d'origine différentes nécessitent une entête Content-Type
correcte. Les restrictions varient selon les navigateurs : IE, Firefox, Chrome, Safari et Opera.<img>
. Les formats d'image supportés, comprenant PNG, JPEG, GIF, BMP, SVG...<video>
et <audio>
.<object>
, <embed>
et <applet>
.@font-face
. Certain navigateurs autorisent les fontes cross-origin, d'autres appliquent la same-origin policy.<frame>
et <iframe>
. Un site peut utiliser l'entête X-Frame-Options
pour interdire cela depuis une page n'ayant pas la même origine.Utiliser CORS pour autoriser l'accès cross-origin.
Content-Type
. Par exemple, pour une balise <script>
pointant un document HTML, le navigateur va tenter d'interpréter le code HTML comme du JavaScript. Si votre ressource n'est pas un point d'entrée de votre site, vous pouvez également utiliser un jeton CSRF.Les APIs JavaScript comme iframe.contentWindow
, window.parent
, window.open
et window.opener
autorisent les documents à se référencer directement entre eux. Quand deux documents n'ont pas la même origine, ces références fournissent des accès limités aux objets Window et Location. Certains navigateurs permettent l'accès à plus de propriétés que ce que les spécifications permettent. À la place, vous pouvez utiliser window.postMessage
pour communiquer entre deux documents.