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

Wenn für Ihre Website die Einstellung document.domain verwendet wird, müssen Sie Maßnahmen ergreifen.

Eiji Kitamura

Updates

• 30. Mai 2023: Wir haben angekündigt, dass die Einstellung des document.domain-Setters in Chrome 115 wirksam wird.
• 7. April 2023: Wir haben ein Problem gefunden, bevor diese Änderung in Chrome 112 eingeführt wurde. Der standardmäßig entfernte document.domain-Setter ist derzeit deaktiviert und der neue Einführungstermin ist noch nicht festgelegt. Bitte sehen Sie später noch einmal in diesem Blogpost nach oder abonnieren Sie blink-dev und diesen Thread.
• 20. Januar 2023: Zeitplan aktualisiert: Der document.domain-Setter wird ab Chrome 112 standardmäßig entfernt. Außerdem wird eine Erwähnung der Enterprise-Richtlinie zur Steuerung 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: Mit der neuen Zeitachse aktualisiert: Ab Chrome 100 wird im Bereich „Probleme“ eine Warnung angezeigt, durch die ab Chrome 106 standardmäßig document.domain-Setter entfernt wird.

Warnung:Wenn für Ihre Website eine Lockerung der Richtlinie für denselben Ursprung über document.domain erforderlich ist, müssen Sie Folgendes tun. Lesen Sie weiter, warum dies geändert wird, oder überspringen Sie den Abschnitt Alternativer Code für die ursprungsübergreifende Kommunikation.

document.domain wurde entwickelt, um den Hostnamen der Quelle abzurufen oder festzulegen.

In Chrome können Websites document.domain nicht mehr festlegen. Sie müssen alternative Ansätze wie postMessage() oder die Channel Messaging API verwenden, um ursprungsübergreifend zu kommunizieren. Wir planen, diese Änderung frühestens in Chrome 112 einzuführen. Das hängt jedoch von der Antwort auf die Intent to Ship-Anfrage ab.

Wenn Ihre Website auf die Lockerung der Same-Origin-Richtlinie über document.domain angewiesen ist, damit sie ordnungsgemäß funktioniert, muss sie einen Origin-Agent-Cluster: ?0-Header senden, ebenso wie alle anderen Dokumente, für die dieses Verhalten erforderlich ist. Hinweis: document.domain hat keine Auswirkungen, wenn es nur in einem Dokument festgelegt ist.

Warum sollte document.domain unveränderlich sein?

Viele Websites haben document.domain so eingerichtet, dass die Kommunikation zwischen Seiten gleicher Website, aber ursprungsübergreifend zulässig ist.

Schlüsselbegriff:Gleiche, aber ursprungsübergreifende Websites haben dieselbe eTLD+1, aber unterschiedliche Subdomains.

So verwenden Sie es:

Angenommen, eine Seite unter https://parent.example.com bettet eine iFrame-Seite von https://video.example.com ein. Diese Seiten haben dieselbe eTLD+1 (example.com) mit unterschiedlichen Subdomains. Wenn document.domain für beide Seiten auf 'example.com' festgelegt 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 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. Die aktuelle Diskussion mit anderen Browseranbietern geht in dieselbe Richtung.

Wenn beispielsweise für zwei Seiten document.domain festgelegt ist, können sie so tun, als würden sie denselben Ursprung haben. Das ist besonders wichtig, wenn für diese Seiten ein gemeinsam genutzter Hostingdienst mit verschiedenen Subdomains verwendet wird. Durch die Einstellung von document.domain wird der Zugriff auf alle anderen Websites ermöglicht, die von demselben Dienst gehostet werden. Dadurch können Angreifer leichter auf Ihre Websites zugreifen. Dies ist möglich, weil document.domain den Portnummernteil der Domain ignoriert.

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

In Chrome 112 soll document.domain unveränderlich sein.

Wie kann ich feststellen, ob meine Website betroffen ist?

Wenn Ihre Website von dieser Änderung betroffen ist, werden Sie in Chrome im Bereich „Probleme“ der DevTools gewarnt. Beachten Sie das gelbe Ausrufezeichen oben rechts.

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

Wenn Sie einen Berichtsendpunkt eingerichtet haben, erhalten Sie auch entsprechende Berichte. Weitere Informationen zur Verwendung der Reporting API mit vorhandenen Berichtsabrufdiensten oder zur Entwicklung einer eigenen Lösung

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

Alternative plattformübergreifende Kommunikation

Derzeit haben Sie drei Möglichkeiten, document.domain für Ihre Website zu ersetzen.

postMessage() oder Channel Messaging API 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 bestimmte Anforderungen haben, die nicht mit postMessage() oder der Channel Messaging API funktionieren, teilen Sie uns dies auf Twitter über @ChromiumDev mit oder stellen Sie auf Stack Overflow mit einem document.domain-Tag eine Frage.

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 in Ihrem Dokument festgelegt werden, wenn es standardmäßig unveränderlich ist.

OriginAgentClusterDefaultEnabled für Unternehmensrichtlinie 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.

Browserkompatibilität

• Die Origin-Spezifikation gibt an, dass die Funktion entfernt werden sollte.
• Mozilla hält es für sinnvoll, document.domain standardmäßig zu deaktivieren und einen Prototyp zu erstellen.
• WebKit gab an, dass die Einstellung des document.domain-Setters einigermaßen positiv ist.

Ressourcen

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

Danksagungen

Foto von Braydon Anderson auf Unsplash