Chrome deaktiviert die Änderung von „document.domain“, um die Richtlinie für denselben Ursprung zu lockern

Wenn für deine Website die Einstellung „document.domain“ erforderlich ist, musst du etwas unternehmen.

Eiji Kitamura
Eiji Kitamura

Updates

  • 30. Mai 2023: Wir haben angekündigt, dass in Chrome 115 die Einstellung des Setter document.domain in Kraft tritt.
  • 7. April 2023: Vor der Einführung dieser Änderung in Chrome 112 haben wir ein Problem festgestellt. Der standardmäßig zu entfernende document.domain-Setter ist derzeit gesperrt und der neue Versandmeilenstein ist noch nicht festgelegt. Sehen Sie später in diesem Blogpost nach oder abonnieren Sie blink-dev und diesen Thread.
  • 20. Januar 2023: Aktualisierter Zeitplan: Der document.domain-Setter wird ab Chrome 112 standardmäßig entfernt. Es wird auch eine Erwähnung der Unternehmensrichtlinie zum Steuern des document.domain-Verhaltens hinzugefügt.
  • 25. Juli 2022: Aktualisierter Zeitplan: Der document.domain-Setter wird ab Chrome 109 standardmäßig entfernt.
  • 4. Februar 2022: Aktualisiert mit dem neuen Zeitplan: Ab Chrome 100 wird im Bereich „Probleme“ eine Warnung angezeigt. Ab Chrome 106 wird der document.domain-Setter standardmäßig entfernt.

document.domain wurde entwickelt, um den Hostnamen des Ursprungs abzurufen oder festzulegen.

In Chrome können Websites document.domain nicht festlegen. Du musst alternative Ansätze wie postMessage() oder die Channel Messaging API verwenden, um ursprungsübergreifend zu kommunizieren. Diese Änderung soll frühestens in Chrome 112 verfügbar sein. Das hängt jedoch von der Antwort auf den Intent to Ship ab.

Wenn für deine Website eine Lockerung der Same-Origin-Policy über document.domain erforderlich ist, muss die Website wie alle anderen Dokumente, für die dieses Verhalten erforderlich ist, einen Origin-Agent-Cluster: ?0-Header senden. Hinweis: document.domain hat keine Auswirkungen, wenn es nur von einem Dokument festgelegt wird.

Warum sollte document.domain unveränderlich gemacht werden?

Viele Websites legen document.domain so fest, dass die Kommunikation zwischen Seiten mit gleicher Website, aber ursprungsübergreifend erlaubt wird.

So wird sie verwendet:

Angenommen, eine Seite unter https://parent.example.com bettet eine iFrame-Seite aus https://video.example.com ein. Diese Seiten haben dieselbe eTLD+1 (example.com) mit unterschiedlichen Subdomains. Wenn das document.domain beider Seiten auf 'example.com' gesetzt ist, 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 ursprungsübergreifende DOM-Manipulation für https://parent.example.com für https://video.example.com erstellen.

Websites legen document.domain fest, um die Kommunikation von Dokumenten auf derselben Website zu vereinfachen. Da durch diese Änderung die Richtlinie für denselben Ursprung gelockert wird, kann die übergeordnete Seite auf das Dokument des iFrame zugreifen und die DOM-Baumstruktur durchqueren und umgekehrt.

Diese Methode ist praktisch, birgt aber auch ein Sicherheitsrisiko.

Sicherheitsbedenken bei document.domain

Sicherheitsbedenken im Zusammenhang mit document.domain haben zu einer Änderung der Spezifikation geführt, die Nutzer vor der Verwendung der Spezifikation gewarnt. Die aktuelle Diskussion mit anderen Browseranbietern entwickelt sich in die gleiche Richtung.

Wenn beispielsweise für zwei Seiten document.domain festgelegt ist, können sie so aussehen, als hätten sie denselben Ursprung. Dies ist besonders wichtig, wenn für diese Seiten ein gemeinsamer Hostingdienst mit verschiedenen Subdomains verwendet wird. Wenn Sie document.domain festlegen, erhalten Angreifer Zugriff auf alle anderen Websites, die von demselben Dienst gehostet werden. Dadurch können Angreifer einfacher auf Ihre Websites zugreifen. Das ist möglich, weil document.domain den Portnummernteil der Domain ignoriert.

Weitere Informationen zu den Auswirkungen der Einstellung von document.domain auf die Sicherheit finden Sie auf der MDN-Seite „Document.domain“.

Es ist geplant, document.domain in Chrome 112 unveränderlich zu machen.

Woher weiß ich, ob meine Website betroffen ist?

Wenn deine Website von dieser Änderung betroffen ist, wird in Chrome im Bereich „Probleme mit den Entwicklertools“ eine Warnung angezeigt. Oben rechts sehen Sie eine gelbe Flagge.

Wenn „document.domain“ geändert wird, wird im Bereich „Probleme“ eine Warnung angezeigt.
Wenn „document.domain“ geändert wird, wird im Bereich „Probleme“ eine Warnung angezeigt.

Wenn Sie einen Endpunkt für die Berichterstellung eingerichtet haben, erhalten Sie auch Einstellungsberichte. Weitere Informationen zur Verwendung der Reporting API mit vorhandenen Diensten zur Berichtserfassung oder zum Erstellen einer eigenen Lösung.

Sie können für Ihre Website die Prüfung der eingestellten LightHouse API bestehen, um alle APIs zu finden, die demnächst aus Chrome entfernt werden.

Alternative ursprungsübergreifende Kommunikation

Sie haben derzeit drei Möglichkeiten, document.domain auf Ihrer Website zu ersetzen.

postMessage() oder Channel Messaging API verwenden

In den meisten Anwendungsfällen kann document.domain durch ursprungsübergreifendes 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 durch Senden einer Nachricht über postMessage() zu bearbeiten.
  2. https://video.example.com manipuliert das DOM, sobald die Nachricht eingeht, und informiert das übergeordnete Element über den Erfolg.
  3. https://parent.example.com erkennt den Erfolg an.

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 und finden Sie heraus, wie es funktioniert. Wenn du bestimmte Anforderungen hast, die nicht mit postMessage() oder der Channel Messaging API funktionieren, teile uns dies auf Twitter über @ChromiumDev mit oder stelle auf Stack Overflow ein document.domain-Tag zur Verfügung.

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

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

Origin-Agent-Cluster: ?0

Der Header Origin-Agent-Cluster 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 Ihr Dokument weiterhin document.domain festlegen, auch wenn er standardmäßig unveränderlich wird.

OriginAgentClusterDefaultEnabled für Unternehmensrichtlinie konfigurieren

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

Browserkompatibilität

Ressourcen

Danksagungen

Foto von Braydon Anderson auf Unsplash