Same-Origin-Policy

Definition eines Origin

Zwei URLs haben denselben Origin, wenn Protokoll, Port (falls angegeben) und Host bei beiden gleich sind. Dies wird möglicherweise als „Schema/Host/Port-Tupel“ oder einfach als „Tupel“ bezeichnet. (Ein „Tupel“ ist eine Menge von Elementen, die zusammen ein Ganzes bilden – eine allgemeine Form für Doppel-/Dreifach-/Vierfach-/Fünffach-/usw.-Kombinationen.)

Die folgende Tabelle enthält Beispiele für Origin-Vergleiche mit der URL http://store.company.com/dir/page.html:

Geerbte Origins

Skripte, die von Seiten mit einer about:blank- oder einer javascript:-URL ausgeführt werden, erben den Origin des Dokuments, das diese URL enthält, da diese URL-Typen keine Informationen über einen Origin-Server enthalten.

Beispielsweise wird about:blank häufig als URL neuer, leerer Pop-up-Fenster verwendet, in die das übergeordnete Skript Inhalte schreibt (z. B. über den Mechanismus Window.open()). Wenn dieses Pop-up ebenfalls JavaScript enthält, würde dieses Skript denselben Origin wie das Skript erben, das es erstellt hat.

data:-URLs erhalten einen neuen, leeren Sicherheitskontext.

Datei-Origins

Moderne Browser behandeln den Origin von Dateien, die über das Schema file:/// geladen werden, normalerweise als opake Origins. Das bedeutet: Wenn eine Datei beispielsweise andere Dateien aus demselben Ordner einbindet, wird nicht angenommen, dass sie vom selben Origin stammen, und es können CORS-Fehler ausgelöst werden.

Beachten Sie, dass die URL-Spezifikation festlegt, dass der Origin von Dateien implementierungsabhängig ist. Manche Browser behandeln Dateien im selben Verzeichnis oder Unterverzeichnis möglicherweise als gleichen Origin, obwohl dies Sicherheitsauswirkungen hat.

Origin ändern

Eine Seite kann ihren eigenen Origin mit einigen Einschränkungen ändern. Ein Skript kann den Wert von document.domain auf seine aktuelle Domain oder eine übergeordnete Domain seiner aktuellen Domain setzen. Wenn er auf eine übergeordnete Domain der aktuellen Domain gesetzt wird, wird die kürzere übergeordnete Domain für Same-Origin-Prüfungen verwendet.

Angenommen, ein Skript aus dem Dokument unter http://store.company.com/dir/other.html führt Folgendes aus:

document.domain = "company.com";

Danach kann die Seite die Same-Origin-Prüfung mit http://company.com/dir/page.html bestehen (vorausgesetzt, http://company.com/dir/page.html setzt sein document.domain auf "company.com", um anzugeben, dass dies erlaubt werden soll – weitere Informationen finden Sie unter document.domain). company.com könnte document.domain jedoch nicht auf othercompany.com setzen, da dies keine übergeordnete Domain von company.com ist.

Die Portnummer wird vom Browser separat geprüft. Jeder Aufruf von document.domain, einschließlich document.domain = document.domain, führt dazu, dass die Portnummer durch null ersetzt wird. Daher kann man company.com:8080 nicht mit company.com kommunizieren lassen, indem nur im ersten document.domain = "company.com" gesetzt wird. Es muss bei beiden gesetzt werden, sodass ihre Portnummern beide null sind.

Der Mechanismus hat einige Einschränkungen. Beispielsweise löst er eine SecurityError-DOMException aus, wenn sich das Dokument in einem Sandbox-<iframe> befindet. Zudem wirkt sich das Ändern des Origin auf diese Weise nicht auf die Origin-Prüfungen aus, die von vielen Web-APIs verwendet werden (z. B. localStorage, indexedDB, BroadcastChannel, SharedWorker). Eine ausführlichere Liste von Fehlerfällen finden Sie unter Document.domain > Failures.

Netzwerkzugriff zwischen Origins

Die Same-Origin-Policy steuert Interaktionen zwischen zwei verschiedenen Origins, etwa wenn Sie fetch() oder ein <img>-Element verwenden. Diese Interaktionen werden üblicherweise in drei Kategorien eingeteilt:

• Origin-übergreifende Schreibvorgänge sind normalerweise erlaubt. Beispiele sind Links, Weiterleitungen und Formularübermittlungen. Einige HTTP-Anfragen erfordern einen Preflight.
• Origin-übergreifendes Einbetten ist normalerweise erlaubt. (Beispiele sind unten aufgeführt.)
• Origin-übergreifende Lesevorgänge sind normalerweise nicht erlaubt, aber Lesezugriff wird häufig durch Einbetten offengelegt. Beispielsweise können Sie die Abmessungen eines eingebetteten Bildes, die Aktionen eines eingebetteten Skripts oder die Verfügbarkeit einer eingebetteten Ressource auslesen.

Hier sind einige Beispiele für Ressourcen, die Origin-übergreifend eingebettet werden können:

• JavaScript mit <script src="…"></script>. Fehlerdetails für Syntaxfehler sind nur für Skripte mit demselben Origin verfügbar.
• CSS, das mit <link rel="stylesheet" href="…"> angewendet wird. Aufgrund der gelockerten Syntaxregeln von CSS erfordert Origin-übergreifendes CSS einen korrekten Content-Type-Header. Browser blockieren das Laden von Stylesheets, wenn es sich um einen Origin-übergreifenden Ladevorgang handelt, bei dem der MIME-Typ falsch ist und die Ressource nicht mit einem gültigen CSS-Konstrukt beginnt.
• Bilder, die durch <img> angezeigt werden.
• Medien, die durch <video> und <audio> wiedergegeben werden.
• Externe Ressourcen, die mit <object> und <embed> eingebettet werden.
• Schriftarten, die mit @font-face angewendet werden. Einige Browser erlauben Origin-übergreifende Schriftarten, andere erfordern denselben Origin.
• Alles, was durch <iframe> eingebettet wird. Websites können den Header X-Frame-Options verwenden, um Origin-übergreifendes Framing zu verhindern.

Origin-übergreifenden Zugriff erlauben

Verwenden Sie CORS, um Origin-übergreifenden Zugriff zu erlauben. CORS ist ein Teil von HTTP, mit dem Server beliebige andere Hosts angeben können, von denen ein Browser das Laden von Inhalten erlauben soll.

Origin-übergreifenden Zugriff blockieren

• Um Origin-übergreifende Schreibvorgänge zu verhindern, prüfen Sie in der Anfrage ein nicht erratbares Token – bekannt als Cross-Site Request Forgery (CSRF)-Token. Sie müssen Origin-übergreifende Lesevorgänge von Seiten verhindern, die dieses Token benötigen.
• Um Origin-übergreifende Lesevorgänge einer Ressource zu verhindern, stellen Sie sicher, dass sie nicht eingebettet werden kann. Es ist häufig erforderlich, das Einbetten zu verhindern, da das Einbetten einer Ressource immer einige Informationen über sie preisgibt.
• Um Origin-übergreifende Einbettungen zu verhindern, stellen Sie sicher, dass Ihre Ressource nicht als eines der oben aufgeführten einbettbaren Formate interpretiert werden kann. Browser berücksichtigen den Content-Type-Header möglicherweise nicht. Wenn Sie beispielsweise ein <script>-Tag auf ein HTML-Dokument verweisen lassen, versucht der Browser, das HTML als JavaScript zu parsen. Wenn Ihre Ressource kein Einstiegspunkt zu Ihrer Website ist, können Sie auch ein CSRF-Token verwenden, um das Einbetten zu verhindern.

Origin-übergreifender Zugriff auf Skript-APIs

JavaScript-APIs wie iframe.contentWindow, window.parent, window.open und window.opener ermöglichen es Dokumenten, direkt aufeinander zu verweisen. Wenn zwei Dokumente nicht denselben Origin haben, bieten diese Verweise, wie in den nächsten beiden Abschnitten beschrieben, nur sehr eingeschränkten Zugriff auf Window und Location-Objekte.

Um zwischen Dokumenten unterschiedlicher Origins zu kommunizieren, verwenden Sie window.postMessage.

Spezifikation: HTML Living Standard § Cross-origin objects.

Window

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

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

Location

Der folgende Origin-übergreifende Zugriff auf Location-Eigenschaften ist erlaubt:

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

Origin-übergreifender Zugriff auf Datenspeicher

Der Zugriff auf im Browser gespeicherte Daten wie Web Storage und IndexedDB wird nach Origin getrennt. Jeder Origin erhält seinen eigenen separaten Speicher, und JavaScript in einem Origin kann weder aus dem Speicher eines anderen Origin lesen noch in ihn schreiben.

Cookies verwenden eine separate Definition von Origins. Eine Seite kann ein Cookie für ihre eigene Domain oder jede übergeordnete Domain setzen, solange die übergeordnete Domain kein öffentliches Suffix ist. Firefox und Chrome verwenden die Public Suffix List, um zu bestimmen, ob eine Domain ein öffentliches Suffix ist. Beim Setzen eines Cookies können Sie dessen Verfügbarkeit mit den Flags Domain, Path, Secure und HttpOnly einschränken. Beim Lesen eines Cookies können Sie nicht erkennen, wo es gesetzt wurde. Selbst wenn Sie ausschließlich sichere HTTPS-Verbindungen verwenden, kann jedes sichtbare Cookie über eine unsichere Verbindung gesetzt worden sein.

Siehe auch

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