Same-Origin-Policy

Zwei URLs haben denselben Origin, wenn das Protokoll, der Port (falls angegeben) und der Host für beide identisch sind. Dies wird auch oft als "scheme/host/port tuple" oder einfach "tuple" bezeichnet. (Ein "Tuple" ist eine Menge von Elementen, die zusammen ein Ganzes bilden – eine generische Form für Double/Triple/Quadruple/Quintuple/etc.)

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

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

Zum Beispiel wird about:blank oft als URL für neue, leere Popup-Fenster verwendet, in die das Elternskript Inhalte schreibt (z. B. über den Mechanismus Window.open()). Wenn dieses Popup ebenfalls JavaScript enthält, würde dieses Skript denselben Origin erben wie das Skript, das es erstellt hat.

data:-URLs erhalten einen neuen, leeren Sicherheitskontext.

Moderne Browser behandeln den Origin von Dateien, die mit dem Schema file:/// geladen werden, in der Regel als undurchsichtige Origins. Das bedeutet, dass, wenn eine Datei andere Dateien aus demselben Ordner (zum Beispiel) einbindet, nicht angenommen wird, dass sie vom gleichen Origin stammen. Dies kann CORS-Fehler auslösen.

Beachten Sie, dass die URL-Spezifikation angibt, dass der Origin von Dateien implementierungsabhängig ist. Einige Browser behandeln Dateien im selben Verzeichnis oder Unterverzeichnis dennoch als gleichen Origin, was allerdings Sicherheitsimplikationen haben kann.

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

Zum Beispiel: Angenommen, ein Skript des Dokuments 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 anzuzeigen, dass dies erlaubt ist – siehe document.domain für mehr). company.com könnte jedoch nicht document.domain auf othercompany.com setzen, da dies keine Über-Domain von company.com ist.

Die Portnummer wird vom Browser separat überprüft. Jeder Aufruf von document.domain, einschließlich document.domain = document.domain, setzt die Portnummer auf null. Daher kann man nicht company.com:8080 dazu bringen, mit company.com zu sprechen, indem man nur document.domain = "company.com" im Ersten setzt. Es muss in beiden gesetzt werden, damit deren Portnummern beide null sind.

Der Mechanismus hat einige Einschränkungen. Beispielsweise wird ein SecurityError DOMException ausgelöst, wenn die document-domain-Permissions-Policy aktiviert ist oder das Dokument in einem sandboxed <iframe> ist. Das Ändern des Origins auf diese Weise beeinflusst nicht die Origin-Prüfungen vieler Web-APIs (z. B. localStorage, indexedDB, BroadcastChannel, SharedWorker). Eine ausführlichere Liste von Fehlerszenarien finden Sie unter Document.domain > Failures.

Die Same-Origin-Policy kontrolliert die Interaktionen zwischen zwei unterschiedlichen Origins, etwa wenn Sie fetch() oder ein <img>-Element verwenden. Diese Interaktionen werden typischerweise in drei Kategorien eingeteilt:

• Zwischen-Origin-Schreiben ist in der Regel erlaubt. Beispiele sind Links, Weiterleitungen und Formular-Einreichungen. Einige HTTP-Anfragen erfordern Preflight.
• Zwischen-Origin-Einbettung ist in der Regel erlaubt. (Beispiele werden unten aufgeführt.)
• Zwischen-Origin-Lesen ist in der Regel nicht erlaubt, aber Lesezugriff wird oft durch Einbettung offengelegt. Zum Beispiel können Sie die Dimensionen eines eingebetteten Bildes, die Aktionen eines eingebetteten Skripts oder die Verfügbarkeit einer eingebetteten Ressource lesen.

Hier sind einige Beispiele von Ressourcen, die zwischen verschiedenen Origins eingebettet werden können:

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

Verwenden Sie CORS, um Between-Origin-Zugriff zu erlauben. CORS ist ein Teil von HTTP, der es Servern ermöglicht, anzugeben, von welchen anderen Hosts ein Browser das Laden von Inhalten zulassen soll.

• Um Between-Origin-Schreiben zu verhindern, überprüfen Sie ein nicht erratbares Token in der Anfrage – bekannt als Cross-Site-Request-Forgery (CSRF)-Token. Sie müssen Between-Origin-Lesungen von Seiten, die dieses Token benötigen, verhindern.
• Um Between-Origin-Lesungen 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 darüber preisgibt.
• Um Between-Origin-Einbettung zu verhindern, stellen Sie sicher, dass Ihre Ressource nicht als eines der oben genannten einbettbaren Formate interpretiert werden kann. Browser respektieren möglicherweise nicht den Content-Type-Header. 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 für Ihre Site ist, können Sie zur Verhinderung der Einbettung auch ein CSRF-Token verwenden.

... (Der restliche Text wird ebenso entsprechend den oben genannten Regeln übersetzt.)