Chrome отключает изменение document.domain

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

Maud Nalpas

Eiji Kitamura

Предупреждение. Как мы объявили в январе 2022 года , мы прекращаем поддержку установщика document.domain , начиная с Chrome 115 . Если ваш веб-сайт полагается на ослабление политики одного и того же происхождения через document.domain , требуются немедленные действия. Обратите внимание, что использование установщика document.domain ( document.domain = ... ) не вызовет исключения. Это только перестанет иметь эффект. Продолжайте читать больше о том, почему это меняется, или перейдите к альтернативному коду, который вы можете реализовать.

Что меняется и почему?

Начиная с Chrome 115 , веб-сайты не смогут устанавливать document.domain : Chrome сделает document.domain неизменяемым. Для связи между источниками вам необходимо использовать альтернативные подходы, такие как postMessage() или API обмена сообщениями канала.

Обратите внимание, что это изменение будет внедряться постепенно.

Мы ожидаем, что другие браузеры со временем устареют и удалят эту функцию. Подробную информацию см. в разделе совместимости браузеров .

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

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

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

Подробно: зачем делать document.domain неизменяемым?

Как document.domain используется сегодня

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

Сайты с одним и тем же сайтом, но с перекрестным происхождением, имеют один и тот же eTLD+1 , но разные поддомены.

Вот как 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 .

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

• В спецификации HTML указано, что эту функцию следует удалить.
• Mozilla считает, что стоит отключить document.domain по умолчанию .
• WebKit указал, что они умеренно позитивно относятся к прекращению использования установщика document.domain .
• Обсуждение с другими поставщиками браузеров
• Запрос на включение рабочей группы WHATWG/HTML (ожидается опыт экспериментирования)

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

Предупреждение. Обратите внимание, что, начиная с Chrome 115, использование установщика document.domain не будет вызывать исключение, как указано в спецификации . Это только перестанет иметь эффект.

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

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

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

Как я вижу это изменение в действии?

Это изменение будет внедряться постепенно, начиная с Chrome 115 . Чтобы увидеть это изменение в действии, даже если оно еще не реализовано в вашем браузере Chrome, вы можете включить его следующим образом:

1. Откройте chrome://flags/#origin-agent-cluster-default
2. Выберите Включить.
3. Перезапустите Хром.

Какие альтернативы я могу использовать?

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

Используйте postMessage() или Channel Messaging API вместо document.domain

В большинстве случаев использования 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 даже после того, как он станет неизменяемым по умолчанию.

Все остальные документы, требующие такого поведения, также должны будут отправить Origin-Agent-Cluster (обратите внимание, что document.domain не имеет никакого эффекта, если его устанавливает только один документ).

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

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

Ресурсы

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

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

Фото Финана Акбара на Unsplash