Same-Origin-Policy

Definition eines Ursprungs

Zwei URLs haben den gleichen Ursprung, wenn das Protokoll, der Port (falls angegeben) und der Host fr beide identisch sind. Dies wird mglicherweise als "Scheme/Host/Port-Tuple" oder einfach als "Tuple" bezeichnet. (Ein "Tuple" ist eine Menge von Elementen, die zusammen ein Ganzes ergeben - eine generische Form fr Double/Triple/Quadruple/Quintuple/etc.)

Die folgende Tabelle gibt Beispiele fr Herkunftsvergleiche mit der URL http://store.company.com/dir/page.html:

Geerbte Ursprnge

Skripte, die von Seiten mit einer about:blank oder javascript: URL ausgefhrt werden, erben den Ursprung des Dokuments, das diese URL enthlt, da diese Arten von URLs keine Informationen ber einen Ursprungsserver enthalten.

Zum Beispiel wird about:blank oft als URL fr neue, leere Popup-Fenster verwendet, in die das bergeordnete Skript Inhalte schreibt (z.B. ber den -Mechanismus). Wenn dieses Popup auch JavaScript enthlt, wrde dieses Skript den gleichen Ursprung wie das Skript, das es erstellt hat, erben.

data: URLs erhalten einen neuen, leeren Sicherheitskontext.

Datei-Ursprnge

Moderne Browser behandeln den Ursprung von Dateien, die mit dem file:///-Schema geladen werden, normalerweise als opake Ursprnge. Das bedeutet, dass, wenn eine Datei andere Dateien aus demselben Ordner (beispielsweise) einbindet, nicht angenommen wird, dass sie vom gleichen Ursprung stammen, und mglicherweise CORS-Fehler auslsen.

Es ist zu beachten, dass die URL-Spezifikation festlegt, dass der Ursprung von Dateien implementationsabhngig ist und einige Browser Dateien im gleichen Verzeichnis oder Unterverzeichnis als gleiche Herkunft behandeln knnen, obwohl dies Sicherheitsimplikationen hat.

Ursprung ndern

Eine Seite kann ihren eigenen Ursprung mit einigen Einschrnkungen ndern. Ein Skript kann den Wert von document.domain auf seine aktuelle Domain oder eine bergeordnete Domain seiner aktuellen Domain setzen. Wird es auf eine bergeordnete Domain der aktuellen Domain gesetzt, wird die krzere bergeordnete Domain fr Same-Origin-Prfungen verwendet.

Zum Beispiel, wenn ein Skript aus dem Dokument unter http://store.company.com/dir/other.html Folgendes ausfhrt:

document.domain = "company.com";

Anschlieend kann die Seite die Same-Origin-Prfung mit http://company.com/dir/page.html bestehen (angenommen, http://company.com/dir/page.html setzt seine document.domain auf "company.com", um anzuzeigen, dass es dies zulassen mchte - siehe document.domain fr mehr). company.com knnte jedoch nicht document.domain auf othercompany.com setzen, da dies keine bergeordnete Domain von company.com ist.

Die Portnummer wird separat vom Browser berprft. Jeder Aufruf von document.domain, einschlielich document.domain = document.domain, fhrt dazu, dass die Portnummer mit null berschrieben wird. Daher kann man nicht company.com:8080 dazu bringen, mit company.com zu kommunizieren, indem man nur document.domain = "company.com" im ersten setzt. Es muss in beiden gesetzt werden, damit ihre Portnummern beide null sind.

Der Mechanismus hat einige Einschrnkungen. Zum Beispiel wird ein SecurityError DOMException ausgelst, wenn das Dokument in einem sandboxed <iframe> ist, und das ndern des Ursprungs auf diese Weise beeinflusst nicht die Ursprungsberprfungen vieler Web-APIs (z.B. localStorage, indexedDB, BroadcastChannel, SharedWorker). Eine umfassendere Liste von Fehlerfllen finden Sie in Document.domain > Failures.

Netzwerkzugriff ber verschiedene Ursprnge

Die Same-Origin-Policy steuert Interaktionen zwischen zwei verschiedenen Ursprngen, wie z.B. wenn Sie fetch() oder ein <img>-Element verwenden. Diese Interaktionen werden typischerweise in drei Kategorien eingeteilt:

• Cross-Origin-Schreiboperationen sind in der Regel erlaubt. Beispiele sind Links, Weiterleitungen und Formularbermittlungen. Einige HTTP-Anfragen erfordern Preflight.
• Cross-Origin-Einbindung ist typischerweise erlaubt. (Beispiele sind unten aufgefhrt.)
• Cross-Origin-Leseoperationen sind in der Regel nicht erlaubt, aber Lesezugriff wird oft durch Einbindung geleakt. Zum Beispiel knnen Sie die Abmessungen eines eingebetteten Bildes, die Aktionen eines eingebetteten Skripts oder die Verfgbarkeit einer eingebetteten Ressource lesen.

Hier sind einige Beispiele fr Ressourcen, die Cross-Origin eingebettet werden drfen:

• JavaScript mit <script src=""></script>. Fehlerdetails fr Syntaxfehler sind nur fr Skripte mit demselben Ursprung verfgbar.
• CSS, das mit <link rel="stylesheet" href=""> angewendet wird. Aufgrund der entspannten Syntaxregeln von CSS erfordert Cross-Origin CSS einen korrekten Content-Type-Header. Browser blockieren das Laden von Stylesheets, wenn es sich um ein Cross-Origin-Laden handelt, bei dem der MIME-Typ falsch ist und die Ressource nicht mit einem gltigen CSS-Konstrukt beginnt.
• Bilder, die von <img> angezeigt werden.
• Medien, die von <video> und <audio> wiedergegeben werden.
• Externe Ressourcen, die mit <object> und <embed> eingebettet werden.
• Fonts, die mit @font-face angewendet werden. Einige Browser erlauben Cross-Origin-Fonts, andere erfordern den gleichen Ursprung.
• Alles, was von <iframe> eingebettet wird. Websites knnen den X-Frame-Options-Header verwenden, um Cross-Origin-Framing zu verhindern.

Anleitung zum Zulassen von Cross-Origin-Zugriff

Verwenden Sie CORS, um Cross-Origin-Zugriff zu erlauben. CORS ist ein Teil von HTTP, der es Servern ermglicht, andere Hosts zu spezifizieren, von denen ein Browser das Laden von Inhalten erlauben sollte.

Anleitung zum Blockieren von Cross-Origin-Zugriff

• Um Cross-Origin-Schreibvorgnge zu verhindern, berprfen Sie ein nicht erratbares Token in der Anfrage - bekannt als Cross-Site Request Forgery (CSRF)-Token. Sie mssen Cross-Origin-Lesevorgnge von Seiten, die dieses Token erfordern, verhindern.
• Um Cross-Origin-Lesevorgnge einer Ressource zu verhindern, stellen Sie sicher, dass sie nicht einbettbar ist. Es ist oft notwendig, das Einbetten zu verhindern, da das Einbetten einer Ressource immer einige Informationen darber leakt.
• Um Cross-Origin-Einbettungen zu verhindern, stellen Sie sicher, dass Ihre Ressource nicht als eines der einbettbaren Formate interpretiert werden kann. Browser respektieren den Content-Type-Header mglicherweise nicht. Wenn Sie beispielsweise ein <script>-Tag auf ein HTML-Dokument verweisen, versucht der Browser, das HTML als JavaScript zu parsen. Wenn Ihre Ressource kein Einstiegspunkt fr Ihre Website ist, knnen Sie auch ein CSRF-Token verwenden, um das Einbetten zu verhindern.

Zugriff auf Cross-Origin-Skript-APIs

JavaScript-APIs wie iframe.contentWindow, window.parent, window.open und window.opener erlauben es Dokumenten, direkt aufeinander zu verweisen. Wenn zwei Dokumente nicht den gleichen Ursprung haben, bieten diese Verweise nur sehr eingeschrnkten Zugriff auf Window und Location-Objekte, wie in den folgenden zwei Abschnitten beschrieben.

Um zwischen Dokumenten aus verschiedenen Ursprngen zu kommunizieren, verwenden Sie window.postMessage.

Spezifikation: HTML Living Standard Cross-origin objects.

Window

Der folgende Cross-Origin-Zugriff auf diese Window-Eigenschaften ist erlaubt:

Einige Browser erlauben den Zugriff auf mehr Eigenschaften als die oben genannten.

Location

Der folgende Cross-Origin-Zugriff auf Location-Eigenschaften ist erlaubt:

Einige Browser erlauben den Zugriff auf mehr Eigenschaften als die oben genannten.

Zugriff auf Cross-Origin-Datenspeicherung

Der Zugriff auf im Browser gespeicherte Daten wie Web Storage und IndexedDB ist nach Ursprngen getrennt. Jeder Ursprung erhlt seinen eigenen separaten Speicher, und JavaScript in einem Ursprung kann nicht auf den Speicher eines anderen Ursprungs zugreifen oder aus diesem lesen.

Cookies verwenden eine separate Definition von Ursprngen. Eine Seite kann ein Cookie fr ihre eigene Domain oder eine bergeordnete Domain setzen, solange diese bergeordnete Domain keine ffentliche Suffix-Domain ist. Firefox und Chrome verwenden die Public Suffix List, um zu bestimmen, ob eine Domain ein ffentliches Suffix ist. Wenn Sie ein Cookie setzen, knnen Sie seine Verfgbarkeit mit den Flags Domain, Path, Secure und HttpOnly einschrnken. Wenn Sie ein Cookie lesen, knnen Sie nicht sehen, von wo dieses gesetzt wurde. Selbst wenn Sie nur sichere https-Verbindungen verwenden, knnte jedes von Ihnen sichtbare Cookie ber eine unsichere Verbindung gesetzt worden sein.

Siehe auch

• Same Origin Policy beim W3C
• Same-origin policy bei web.dev
• Cross-Origin-Resource-Policy
• Cross-Origin-Embedder-Policy