Chrome wyłączy modyfikację document.domain, aby złagodzić zasadę dotyczącą tej samej domeny

Jeśli Twoja witryna wymaga ustawienia document.domain, musisz podjąć działanie.

Eiji Kitamura

Twitter GitHub Glitch Mastodon

Aktualizacje

• 30 maja 2023 r.: ogłosiliśmy, że wycofanie metody ustawiającej document.domain zacznie obowiązywać w Chrome 115.
• 7 kwietnia 2023 r.: przed wprowadzeniem tej zmiany do Chrome 112 wykryliśmy problem. Konfigurujący document.domain, który ma zostać domyślnie usunięty, jest obecnie zawieszony, a nowy etap dostawy nie jest jeszcze określony. Wróć do tego posta na blogu lub zasubskrybuj blink-dev i ten wątek.
• 20 stycznia 2023 r.: zaktualizowaliśmy oś czasu – od wersji Chrome 112 narzędzie document.domain będzie domyślnie usuwane. Dodaliśmy też wzmiankę o zasadach przedsiębiorstwa kontrolujących działanie document.domain.
• 25 lipca 2022 roku: zaktualizowaliśmy oś czasu – od wersji Chrome 109 narzędzie document.domain będzie domyślnie usuwane.
• 4 lutego 2022 roku: zaktualizowaliśmy nowy harmonogram – od wersji Chrome 100 w panelu Problemy pojawi się ostrzeżenie. Od wersji Chrome 106 domyślnie usuniemy ustawienie document.domain.

Ostrzeżenie: jeśli Twoja witryna wymaga złagodzenia zasady dotyczącej tej samej domeny w document.domain, musisz podjąć działanie. Przeczytaj więcej na temat tej zmiany lub przejdź do alternatywnego kodu do komunikacji między domenami.

Zadanie document.domain zostało zaprojektowane do pobierania lub ustawiania nazwy hosta źródła.

W Chrome strony nie będą mogły ustawić wartości document.domain. Do komunikacji między domenami musisz użyć alternatywnych metod, takich jak postMessage() czy Channel Messaging API. Planujemy jak najszybciej wprowadzić tę zmianę w Chrome 112, ale zależy to od reakcji na Zamiar wysyłki.

Jeśli do prawidłowego działania Twoja witryna wymaga złagodzenia zasad dotyczących tej samej domeny za pomocą metody document.domain, musi ona wysyłać nagłówek Origin-Agent-Cluster: ?0, podobnie jak wszystkie inne dokumenty, które tego wymagają (pamiętaj, że funkcja document.domain nie zadziała, jeśli ustawi go tylko 1 dokument).

Dlaczego ustawienie document.domain ma być stałe?

Wiele witryn ustawia document.domain, aby umożliwić komunikację między stronami w tej samej witrynie, ale z innych domen.

Kluczowy termin: witryny w tej samej witrynie, ale z innych domen, mają taką samą wartość eTLD + 1, ale różne subdomeny.

Oto jak to działa:

Załóżmy, że strona w domenie https://parent.example.com zawiera stronę iframe z witryny https://video.example.com. Te strony mają tę samą wartość eTLD + 1 (example.com) z różnymi subdomenami. Jeśli parametr document.domain obu stron ma wartość 'example.com', przeglądarka traktuje 2 źródła tak, jakby były tego samego pochodzenia.

Ustaw document.domain dla https://parent.example.com:

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

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

Ustaw document.domain dla https://video.example.com:

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

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

Możesz teraz utworzyć manipulację DOM między domenami w tabeli https://parent.example.com z elementem https://video.example.com.

Witryny ustawiają document.domain, aby ułatwić komunikację między dokumentami z tej samej witryny. Ta zmiana łagodzi zasadę tego samego źródła, więc strona nadrzędna ma dostęp do dokumentu elementu iframe i przemierza drzewo DOM (i odwrotnie).

Jest to wygodna technika, ale stanowi zagrożenie dla bezpieczeństwa.

Problemy dotyczące bezpieczeństwa związane z usługą document.domain

Obawy związane z bezpieczeństwem związane z usługą document.domain spowodowały zmianę w specyfikacji, która ostrzega użytkowników, aby nie korzystali z niej. Obecna dyskusja z innymi dostawcami przeglądarek zmierza w tym samym kierunku.

Jeśli np. 2 strony z ustawieniem document.domain mogą udawać, że są tego samego pochodzenia. Jest to szczególnie ważne, gdy strony te korzystają z udostępnianej usługi hostingowej z różnymi subdomenami. Skonfigurowanie ustawienia document.domain daje dostęp do wszystkich stron hostowanych przez tę samą usługę, co ułatwia hakerom dostęp do Twoich witryn. Jest to możliwe, ponieważ document.domain ignoruje część numeru portu w domenie.

Aby dowiedzieć się więcej o wpływie ustawienia document.domain na bezpieczeństwo, przeczytaj stronę „Document.domain” w MDN.

Planujemy wprowadzić w Chrome 112 stałe ustawienie document.domain.

Jak sprawdzić, czy dotyczy to mojej witryny?

Jeśli ta zmiana będzie miała wpływ na Twoją witrynę, Chrome wyświetli ostrzeżenie w panelu Problemy w Narzędziach deweloperskich. Zwróć uwagę na żółtą flagę w prawym górnym rogu.

W przypadku zmodyfikowania parametru document.domain w panelu Problemy pojawia się ostrzeżenie.

Jeśli masz skonfigurowany punkt końcowy raportowania, będziesz też otrzymywać raporty o wycofaniu. Dowiedz się więcej o tym, jak używać interfejsu API do raportowania za pomocą istniejących usług zbierania raportów lub tworzenia własnego rozwiązania wewnętrznego.

Aby znaleźć wszystkie interfejsy API, które mają zostać usunięte z Chrome, możesz przeprowadzić w swojej witrynie kontrolę wycofanych interfejsów API LightHouse.

Alternatywna komunikacja między domenami

Obecnie możesz zastąpić atrybut document.domain w swojej witrynie na 3 sposoby.

Użyj interfejsu postMessage() lub interfejsu Channel Messaging API

W większości przypadków interfejsy API z innych domen postMessage() lub Channel Messaging API mogą zastąpić document.domain.

W tym przykładzie:

1. https://parent.example.com żąda https://video.example.com w elemencie iframe, by manipulować DOM, wysyłając wiadomość przez postMessage().
2. https://video.example.com manipuluje DOM natychmiast po otrzymaniu wiadomości i powiadamia o powodzeniu z powrotem do systemu nadrzędnego.
3. https://parent.example.com potwierdza sukces.

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
  }
});

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);
});

Wypróbuj go i zobacz, jak to działa. Jeśli masz konkretne wymagania, które nie będą działać w usłudze postMessage() ani w interfejsie Channel Messaging API, daj nam znać na Twitterze za pomocą @ChromiumDev lub zapytaj na Stack Overflow, używając tagu document.domain.

W ostateczności wyślij nagłówek Origin-Agent-Cluster: ?0

Jeśli masz ważne powody, aby kontynuować konfigurowanie funkcji document.domain, możesz wysłać nagłówek odpowiedzi Origin-Agent-Cluster: ?0 wraz z dokumentem docelowym.

Origin-Agent-Cluster: ?0

Nagłówek Origin-Agent-Cluster informuje przeglądarkę, czy dokument ma być obsługiwany przez klaster agentów ze źródłem jako kluczem. Więcej informacji o Origin-Agent-Cluster znajdziesz w artykule Wysyłanie prośby o izolację wydajności za pomocą nagłówka Origin-Agent-Cluster.

Gdy wyślesz ten nagłówek, dokument może nadal ustawiać document.domain, nawet gdy domyślnie stanie się on stały.

Konfigurowanie zasady OriginAgentClusterDefaultEnabled dla zasady przedsiębiorstwa

Opcjonalnie administrator może skonfigurować zasadę OriginAgentClusterDefaultEnabled na false, aby domyślnie skonfigurować ustawienie document.domain w instancjach Chrome w całej organizacji. Więcej informacji znajdziesz w artykule Lista zasad Chrome Enterprise i zarządzanie nimi | Dokumentacja.

Zgodność z przeglądarką

• Specyfikacja źródła określa, że obiekt powinien zostać usunięty.
• Mozilla rozważa wyłączenie zasady document.domain jako domyślnego wartego prototypowania.
• Zespół WebKit zaznaczył, że są umiarkowanie pozytywne co do wycofania metody ustawiającej document.domain.

Zasoby

• Document.domain – internetowe interfejsy API | MDN
• Izolacja źródeł i wycofywanie document.domain
• Wycofuję document.domain. · Problem nr 564 · w3ctag/design-reviews

Podziękowania

Zdjęcie: Braydon Anderson, Unsplash