Chrome deaktiviert das Ändern von „document.domain“

Wenn für Ihre Website die Einstellung „document.domain“ erforderlich ist, ist Ihre Aktion erforderlich.

Maud Nalpas

Eiji Kitamura

Warnung:Wie wir im Januar 2022 angekündigt haben, wird der document.domain-Setter ab Chrome 115 eingestellt. Wenn Ihre Website auf die Lockerung der Same-Origin-Richtlinie über document.domain angewiesen ist, müssen Sie sofort Maßnahmen ergreifen. Hinweis: Wenn Sie den document.domain-Setter (document.domain = ...) verwenden, wird keine Ausnahme ausgelöst. Die Funktion ist dann nur noch nicht mehr aktiv. Lies weiter, um mehr über die Gründe für diese Änderung zu erfahren, oder gehe direkt zum alternativen Code, den du implementieren kannst.

Was ändert sich und warum?

Ab Chrome 115 können Websites document.domain nicht mehr festlegen: document.domain wird in Chrome unveränderlich. Für die ursprungsübergreifende Kommunikation müssen Sie alternative Ansätze wie postMessage() oder die Channel Messaging API verwenden.

Diese Änderung wird nach und nach eingeführt.

Wir gehen davon aus, dass andere Browser diese Funktion irgendwann einstellen und entfernen werden. Weitere Informationen finden Sie im Abschnitt Browserkompatibilität.

Warum sollte document.domain unveränderlich sein?

document.domain wurde entwickelt, um den Hostnamen des Ursprungs abzurufen oder festzulegen. Viele Websites legen document.domain fest, um die Kommunikation zwischen ursprungsübergreifenden Seiten auf derselben Website zu ermöglichen.

Diese Methode ist zwar praktisch, birgt aber ein Sicherheitsrisiko, da die Same-Origin-Richtlinie gelockert wird. Sicherheitsbedenken im Zusammenhang mit document.domain haben zu einer Änderung der Spezifikation geführt, in der Nutzer vor der Verwendung gewarnt werden.

Im Detail: Warum sollte document.domain unveränderlich sein?

So wird document.domain heute verwendet

Viele Websites legen document.domain so fest, dass die Kommunikation zwischen ursprungsübergreifenden Seiten auf derselben Website zulässig ist.

Websites mit derselben Website, aber unterschiedlichen Ursprüngen haben dieselbe eTLD+1, aber unterschiedliche Subdomains.

So wurde document.domain bisher verwendet:

Angenommen, auf einer Seite auf https://parent.example.com ist eine iFrame-Seite von https://video.example.com eingebettet. Diese Seiten haben dieselbe eTLD+1 (example.com) mit unterschiedlichen Subdomains. Wenn die document.domain-Werte beider Seiten auf 'example.com' festgelegt sind, behandelt der Browser die beiden Ursprünge so, als hätten sie denselben Ursprung.

Legen Sie document.domain für https://parent.example.com fest:

// Confirm the current origin of "parent.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

Legen Sie document.domain für https://video.example.com fest:

// Confirm the current origin of "video.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

Sie können jetzt eine domänenübergreifende DOM-Manipulation auf https://parent.example.com gegen https://video.example.com erstellen.

Websites legen document.domain fest, damit Dokumente auf derselben Website einfacher miteinander kommunizieren können. Da durch diese Änderung die Richtlinie für denselben Ursprung gelockert wird, kann die übergeordnete Seite auf das Dokument des Iframes zugreifen und den DOM-Baum durchlaufen. Das gilt auch umgekehrt.

Das ist eine praktische Methode, birgt jedoch ein Sicherheitsrisiko.

Sicherheitsbedenken bei document.domain

Sicherheitsbedenken im Zusammenhang mit document.domain haben zu einer Änderung der Spezifikation geführt, in der Nutzer davor gewarnt werden, sie zu verwenden.

Wenn beispielsweise zwei Seiten document.domain festlegen, können sie so tun, als hätten sie denselben Ursprung. Das ist besonders wichtig, wenn für diese Seiten ein gemeinsam genutzter Hostingdienst mit verschiedenen Subdomains verwendet wird. Wenn Sie document.domain festlegen, wird der Zugriff auf alle anderen Websites gewährt, die von demselben Dienst gehostet werden. Das erleichtert Angreifern den Zugriff auf Ihre Websites. Das ist möglich, weil document.domain den Teil der Domain mit der Portnummer ignoriert.

Weitere Informationen zu den Sicherheitsaspekten der Einstellung document.domain finden Sie auf der MDN-Seite „Document.domain“.

Browserkompatibilität

• Die HTML-Spezifikation besagt, dass die Funktion entfernt werden sollte.
• Mozilla hält es für sinnvoll, ein Prototyping für die Standarddeaktivierung von document.domain durchzuführen.
• WebKit hat angegeben, dass es die Einstellung des document.domain-Setters mäßig positiv sieht.
• Unterhaltung mit anderen Browseranbietern
• Pull-Request der WHATWG-/HTML-Arbeitsgruppe (ausstehende Testerfahrung)

Wie kann ich feststellen, ob meine Website betroffen ist?

Warnung:Ab Chrome 115 wird bei Verwendung des document.domain-Setters gemäß der Spezifikation keine Ausnahme ausgelöst. Die Wirkung lässt nur nach.

Wenn Ihre Website von dieser Änderung betroffen ist, werden Sie in Chrome im Bereich „Probleme“ der DevTools gewarnt. Diese Warnung wurde 2022 hinzugefügt. Beachten Sie das gelbe Ausrufezeichen oben rechts in den DevTools.

Sie können Ihre Website auch mit der Lighthouse-Prüfung für veraltete APIs prüfen, um alle APIs zu finden, die aus Chrome entfernt werden sollen.

Wenn Sie die Reporting API eingerichtet haben, hat Chrome Ihnen Einstellungsberichte gesendet, um Sie über diese bevorstehende Einstellung zu informieren. Weitere Informationen zur Verwendung der Reporting API mit vorhandenen Berichtsabrufdiensten oder zur Entwicklung einer eigenen Lösung

Wie kann ich diese Änderung in der Praxis sehen?

Die Änderung wird ab Chrome 115 schrittweise eingeführt. Wenn Sie diese Änderung ausprobieren möchten, auch wenn sie noch nicht in Ihrem Chrome-Browser eingeführt wurde, können Sie sie so aktivieren:

1. chrome://flags/#origin-agent-cluster-default öffnen
2. Wählen Sie Aktivieren aus.
3. Starten Sie Chrome neu.

Welche Alternativen kann ich verwenden?

Am besten ändern Sie document.domain gar nicht, indem Sie beispielsweise die Seite und alle zugehörigen Frames am selben Ursprung hosten. Das funktioniert in allen Versionen aller Browser. Dies kann jedoch eine erhebliche Überarbeitung einer Anwendung erfordern. Daher lohnt es sich, auch nach Alternativen zu suchen, die weiterhin plattformübergreifende Zugriffe unterstützen.

postMessage() oder Channel Messaging API anstelle von document.domain verwenden

In den meisten Anwendungsfällen kann document.domain durch das ursprungsübergreifende postMessage() oder die Channel Messaging API ersetzt werden.

Im folgenden Beispiel gilt:

1. https://parent.example.com fordert https://video.example.com in einem Iframe an, um das DOM zu manipulieren, indem eine Nachricht über postMessage() gesendet wird.
2. https://video.example.com manipuliert das DOM, sobald es die Nachricht empfängt, und benachrichtigt das übergeordnete Element über den Erfolg.
3. https://parent.example.com bestätigt den Erfolg.

Am https://parent.example.com:

// Send a message to https://video.example.com
iframe.postMessage('Request DOM manipulation', 'https://video.example.com');

// Receive messages
iframe.addEventListener('message', (event) => {
  // Reject all messages except ones from https://video.example.com
  if (event.origin !== 'https://video.example.com') return;

  // Filter success messages
  if (event.data === 'succeeded') {
    // DOM manipulation is succeeded
  }
});

Am https://video.example.com:

// Receive messages
window.addEventListener('message', (event) => {
  // Reject all messages except ones from https://parent.example.com
  if (event.origin !== 'https://parent.example.com') return;

  // Do a DOM manipulation on https://video.example.com.

  // Send a success message to https://parent.example.com
  event.source.postMessage('succeeded', event.origin);
});

Probieren Sie es aus. Wenn Sie spezielle Anforderungen haben, die nicht mit postMessage() oder der Channel Messaging API funktionieren, können Sie sich über Twitter unter @ChromiumDev an uns wenden oder eine Frage auf Stack Overflow mit dem document.domain-Tag stellen.

Als letzte Option können Sie den Origin-Agent-Cluster: ?0-Header senden.

Wenn Sie triftige Gründe haben, document.domain weiterhin festzulegen, können Sie den Antwortheader Origin-Agent-Cluster: ?0 zusammen mit dem Zieldokument senden.

Origin-Agent-Cluster: ?0

Der Origin-Agent-Cluster-Header weist den Browser an, ob das Dokument vom an Ursprünge gebundenen Agent-Cluster verarbeitet werden soll oder nicht. Weitere Informationen zu Origin-Agent-Cluster finden Sie unter Leistungsisolation mit dem Origin-Agent-Cluster-Header anfordern.

Wenn Sie diesen Header senden, kann document.domain auch dann für Ihr Dokument festgelegt werden, wenn es standardmäßig unveränderlich ist.

Für alle anderen Dokumente, für die dieses Verhalten erforderlich ist, muss ebenfalls Origin-Agent-Cluster gesendet werden. Hinweis: document.domain hat keine Auswirkungen, wenn es nur von einem Dokument festgelegt wird.

OriginAgentClusterDefaultEnabled für Unternehmensrichtlinien konfigurieren

Optional kann Ihr Administrator die OriginAgentClusterDefaultEnabled-Richtlinie auf false konfigurieren, damit document.domain standardmäßig in Chrome-Instanzen in Ihrer Organisation festgelegt werden kann. Weitere Informationen finden Sie unter Chrome Enterprise-Richtlinienliste und -verwaltung | Dokumentation.

Ressourcen

• Document.domain – Web APIs | MDN
• Ursprungsisolation und Einstellung von document.domain
• Einstellung von document.domain. · Issue #564 · w3ctag/design-reviews

Danksagungen

Foto von Finan Akbar auf Unsplash