Dokument: domain Eigenschaft

Wert

Ein String.

Ausnahmen

SecurityError DOMException

Das Dokument darf seine Domain nicht setzen, beispielsweise wenn es im Sandkasten ausgeführt wird oder einen undurchsichtigen Ursprung hat. Siehe Abschnitt über Fehler für Details.

Beispiele

Die Domain abrufen

Für Code, der unter der URL https://developer.mozilla.org/de/docs/Web ausgeführt wird, würde dieses Beispiel currentDomain auf den String "developer.mozilla.org" setzen.

const currentDomain = document.domain;

Der Getter für diese Eigenschaft gibt den Domain-Teil des Ursprungs des aktuellen Dokuments zurück. In den meisten Fällen wird dies der Hostname-Teil der URL des Dokuments sein. Es gibt jedoch einige Ausnahmen:

• Wenn die Seite einen undurchsichtigen Ursprung hat, z.B. für eine Seite mit einer Daten-URL, dann wird sie den leeren String zurückgeben.
• Wenn der document.domain-Setter verwendet wurde, dann wird der gesetzte Wert zurückgegeben.

Obwohl der Getter nicht in der gleichen Weise gefährlich ist wie der Setter, ist es wahrscheinlich einfacher und nützlicher, die Location.hostname-Eigenschaft zu verwenden. Dann können Sie document.domain vollständig vermeiden:

const currentHostname = location.hostname;

Für die URL https://developer.mozilla.org/de/docs/Web ist currentHostname ebenfalls der String "developer.mozilla.org". Andere Alternativen, die leicht unterschiedliche Informationen liefern, sind Location.host, das den Port enthält, und Window.origin, das den vollen Ursprung liefert.

Die Domain setzen

document.domain = domainString;

Der Setter für diese Eigenschaft kann verwendet werden, um den Ursprung einer Seite zu ändern und damit zu verändern, wie bestimmte Sicherheitsprüfungen durchgeführt werden. Er kann nur auf die gleiche oder eine übergeordnete Domain gesetzt werden. Zum Beispiel, wenn https://a.example.com und https://b.example.com beide verwenden

document.domain = "example.com";

dann haben sie beide ihren Ursprung modifiziert, um die gleiche Domain zu haben, und sie können nun direkt auf das DOM des jeweils anderen zugreifen—trotz Cross-Origin, das normalerweise einen solchen Zugriff verhindern würde.

Beachten Sie, dass das Setzen von document.domain auf seinen aktuellen Wert keine No-Op ist. Es ändert dennoch den Ursprung. Zum Beispiel, wenn eine Seite setzt

document.domain = document.domain;

dann wird sie als Cross-Origin von allen anderen normalerweise gleichen Ursprungsseiten gezählt, die nicht dasselbe getan haben.

Veraltend

Der document.domain-Setter ist veraltet. Er untergräbt die Sicherheitsvorkehrungen, die von der Same-Origin-Policy bereitgestellt werden, und kompliziert das Ursprungsmodell in Browsern, was zu Interoperabilitätsproblemen und Sicherheitslücken führt.

Der Versuch, document.domain zu setzen, ist gefährlich. Er öffnet den vollständigen Zugriff auf das DOM einer Seite von allen Subdomains, was wahrscheinlich nicht beabsichtigt ist. Er entfernt auch die Port-Komponente vom Ursprung, sodass Ihre Seite jetzt von anderen Seiten mit derselben IP-Adresse oder demselben Host-Komponenten, sogar auf einem anderen Port, zugänglich gemacht werden kann.

Dies ist besonders unsicher bei gemeinsam genutztem Hosting. Beispielsweise ist ein anderer Kunde des Shared Hosting in der Lage, eine Seite unter derselben IP-Adresse, jedoch auf einem anderen Port zu hosten. Das Setzen von document.domain entfernt dann den Same-Origin-Schutz, der normalerweise verhindert, dass diese andere Kundenseite auf die Daten Ihrer Seite zugreift.

Ähnliche Probleme treten bei Shared-Hosting-Seiten auf, die jedem Kunden eine andere Subdomain zuweisen. Wenn eine Seite document.domain setzt, kann jeder andere Kunde auf einem anderen Subdomain dasselbe tun und beginnt, auf die Daten der originalen Seite zuzugreifen.

Anstatt document.domain zur Erleichterung der Cross-Origin-Kommunikation zu verwenden, sollten Sie Window.postMessage verwenden, um eine asynchrone Nachricht an den anderen Ursprung zu senden. Dieser kontrollierte Zugriff über Nachrichtenübermittlung ist viel sicherer als die pauschale Offenlegung aller Daten, die durch document.domain verursacht wird.

Fehler

Der Setter wird einen SecurityError DOMException in mehreren Fällen werfen:

• Das Dokument befindet sich in einem sandboxed <iframe>.
• Das Dokument hat keinen Browsing-Kontext.
• Die effektive Domain des Dokuments ist null.
• Der angegebene Wert ist weder derselbe wie der aktuelle Hostname der Seite, noch eine übergeordnete Domain davon.

Als Beispiel für diesen letzten Fehlerfall, der Versuch, document.domain auf "example.org" zu setzen, während man auf https://example.com/ ist, wird einen Fehler werfen.

Zusätzlich wird er als Teil seiner Veralterung nichts tun, wenn er mit bestimmten modernen Isolationstechniken kombiniert wird:

• Wenn er auf einer kreuzursprungs-isolierten Seite verwendet wird, d.h. auf einer Seite, die die entsprechenden Werte für die Cross-Origin-Opener-Policy und Cross-Origin-Embedder-Policy HTTP-Header verwendet
• Wenn er auf einer ursprungs-isolierten Seite verwendet wird, d.h. auf einer Seite, die den Origin-Agent-Cluster Experimentell HTTP-Header verwendet

Schließlich ändert das Setzen von document.domain nicht den Ursprung, der für Ursprungsüberprüfungen durch einige Web-APIs verwendet wird, wodurch ein Zugriff auf Sub-Domains über diesen Mechanismus verhindert wird. Betroffene APIs umfassen (aber sind nicht beschränkt auf): Window.localStorage, IndexDB API, BroadcastChannel, SharedWorker.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Same-Origin-Policy
• Location.hostname
• Location.host
• Window.origin