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

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

Eiji Kitamura

Обновления

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

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

В Chrome веб-сайты не смогут установить document.domain . Для связи между источниками вам потребуется использовать альтернативные подходы, такие как postMessage() или Channel Messaging API. Мы планируем выпустить это изменение в 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». Обратите внимание на желтый флажок в правом верхнем углу.

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

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

Альтернативная связь между источниками

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

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

В большинстве случаев использования postMessage() или Channel Messaging API из разных источников могут заменить document.domain .

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

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() или Channel Messaging API, сообщите нам об этом в Twitter через @ChromiumDev или спросите в Stack Overflow с помощью тега document.domain .

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

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

Origin-Agent-Cluster: ?0

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

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

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

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

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

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

Ресурсы

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

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

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