Chrome отключит возможность изменения document.domain, чтобы смягчить политику одинакового происхождения

Если ваш веб-сайт зависит от настройки document.domain , требуется ваше действие.

Eiji Kitamura

Обновления

• 30 мая 2023 г .: мы объявили , что прекращение поддержки сеттера document.domain вступит в силу в Chrome 115.
• 7 апреля 2023 г .: Мы выявили проблему перед отправкой этого изменения в Chrome 112. document.domain setter, который должен быть удален по умолчанию, в настоящее время приостановлен, и новый этап доставки еще не определен. Пожалуйста, проверьте эту запись в блоге или подпишитесь на blink-dev и эту ветку .
• 20 января 2023 г .: обновлена ​​временная шкала — сеттер document.domain будет удален по умолчанию, начиная с Chrome 112. Также добавлено упоминание о корпоративной политике для управления поведением document.domain .
• 25 июля 2022 г .: обновленная временная шкала — сеттер document.domain будет удален по умолчанию, начиная с Chrome 109.
• 4 февраля 2022 г .: обновлено с учетом новой временной шкалы — начиная с Chrome 100 на панели «Проблемы» будет отображаться предупреждение, а начиная с Chrome 106 по умолчанию будет удален сеттер document.domain .

document.domain был разработан для получения или установки имени хоста источника.

В Chrome веб-сайты не смогут устанавливать document.domain . Вам нужно будет использовать альтернативные подходы, такие как postMessage() или API Channel Messaging, для связи между источниками. Мы нацелены на Chrome 112, чтобы отправить это изменение как можно скорее, но это зависит от ответа на Intent to Ship .

Если для корректной работы вашего веб-сайта требуется смягчение политики единого источника через document.domain , сайту необходимо будет отправить заголовок Origin-Agent-Cluster: ?0 , как и всем другим документам, требующим такого поведения (обратите внимание, что document.domain не оказывает никакого эффекта, если его задает только один документ).

Зачем делать document.domain неизменяемым?

Многие веб-сайты устанавливают document.domain для обеспечения связи между страницами одного сайта, но с разным источником .

Вот как это используется:

Допустим, страница на https://parent.example.com встраивает страницу iframe из https://video.example.com . Эти страницы имеют одинаковый eTLD+1 ( example.com ) с разными поддоменами. Когда document.domain обеих страниц установлен на 'example.com' , браузер обрабатывает два источника как если бы они были одного происхождения.

Установите document.domain для 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);

Установите document.domain для 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);

Теперь вы можете создать кросс-доменную манипуляцию DOM на https://parent.example.com и https://video.example.com .

Веб-сайты устанавливают document.domain , чтобы сделать возможным более легкое взаимодействие документов одного сайта. Поскольку это изменение ослабляет политику одного источника , родительская страница может получить доступ к документу iframe и пройти по дереву DOM, и наоборот.

Это удобный метод, однако он создает риск для безопасности.

Проблемы безопасности с document.domain

Проблемы безопасности вокруг document.domain привели к изменению спецификации, которая предупреждает пользователей о необходимости избегать его использования . Текущее обсуждение с другими поставщиками браузеров движется в том же направлении.

Например, когда две страницы устанавливают document.domain , они могут притворяться, что они имеют один и тот же источник. Это особенно критично, когда эти страницы используют общий хостинг с разными поддоменами. Установка document.domain открывает доступ ко всем другим сайтам, размещенным на том же сервисе, что упрощает злоумышленникам доступ к вашим сайтам. Это возможно, поскольку document.domain игнорирует часть номера порта домена.

Чтобы узнать больше о последствиях настройки document.domain для безопасности, прочитайте страницу «Document.domain» на MDN .

Chrome планирует сделать document.domain неизменяемым в Chrome 112.

Как узнать, затронут ли мой сайт?

Если ваш сайт затронут этим изменением, Chrome предупредит об этом на панели DevTools Issues. Обратите внимание на желтый флаг в правом верхнем углу.

Если у вас настроена конечная точка отчетности, вам также будут отправлены отчеты об устаревании. Узнайте больше о том, как использовать API отчетности с существующими службами сбора отчетов или путем создания собственного внутреннего решения.

Вы можете запустить свой сайт через аудит устаревших API LightHouse, чтобы найти все API, которые планируется удалить из Chrome.

Альтернативная кросс-источниковая коммуникация

На данный момент у вас есть три варианта замены document.domain для вашего веб-сайта.

Используйте postMessage() или API обмена сообщениями по каналам

В большинстве случаев использования document.domain можно заменить кросс-доменным postMessage() или API обмена сообщениями по каналам .

В следующем примере:

1. https://parent.example.com запрашивает https://video.example.com внутри iframe для управления DOM путем отправки сообщения через postMessage() .
2. https://video.example.com обрабатывает DOM сразу после получения сообщения и уведомляет об успешном выполнении родительский элемент.
3. https://parent.example.com подтверждает успех.

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

Попробуйте и посмотрите, как это работает. Если у вас есть особые требования, которые не будут работать с postMessage() или API Channel Messaging, сообщите нам об этом в Twitter через @ChromiumDev или спросите на Stack Overflow с тегом document.domain .

В крайнем случае отправьте заголовок Origin-Agent-Cluster: ?0

Если у вас есть веские причины продолжить настройку document.domain , вы можете отправить заголовок ответа Origin-Agent-Cluster: ?0 вместе с целевым документом.

Origin-Agent-Cluster: ?0

Заголовок Origin-Agent-Cluster сообщает браузеру, должен ли документ обрабатываться кластером агентов с ключом origin или нет. Чтобы узнать больше о Origin-Agent-Cluster , прочитайте раздел Запрос изоляции производительности с заголовком Origin-Agent-Cluster .

При отправке этого заголовка ваш документ может продолжать устанавливать document.domain даже после того, как он станет неизменяемым по умолчанию.

Настройте OriginAgentClusterDefaultEnabled для корпоративной политики

При желании ваш администратор может настроить политику OriginAgentClusterDefaultEnabled на false , чтобы сделать document.domain настраиваемым по умолчанию на экземплярах Chrome в вашей организации. Чтобы узнать больше, прочитайте Chrome Enterprise Policy List & Management | Documentation .

Совместимость с браузерами

• В спецификации Origin указано, что эту функцию следует удалить.
• Mozilla считает, что отключение document.domain по умолчанию заслуживает прототипирования .
• WebKit указал, что они умеренно положительно относятся к прекращению поддержки document.domain setter .

Ресурсы

• Document.domain — веб-API | MDN
• Изоляция источника и прекращение поддержки document.domain
• Устаревание document.domain . · Проблема № 564 · w3ctag/design-reviews

Благодарности

Фото Брейдона Андерсона на Unsplash