HTTP Cross-Origin-Opener-Policy (COOP) — это заголовок ответа, который позволяет веб-сайту управлять тем, будет ли новый документ верхнего уровня, открытый с помощью Window.open() или при переходе на новую страницу, открыт в той же группе контекста просмотра (BCG) или в новой группе контекста просмотра.

При открытии в новой BCG все ссылки между новым документом и открывшим его документом разрываются, а новый документ может быть изолирован от открывшего его документа на уровне процесса. Это гарантирует, что потенциальные злоумышленники не смогут открыть ваши документы с помощью Window.open(), а затем использовать возвращённое значение для доступа к глобальному объекту документа, и тем самым предотвращает ряд межсайтовых атак, называемых XS-Leaks.

Это также означает, что любой объект, открытый вашим документом в новой BCG, не сможет получить к нему доступ с помощью window.opener. Это позволяет лучше контролировать ссылки на окно, чем rel=noopener, который влияет на переходы на другие страницы, но не на документы, открытые с помощью Window.open().

Поведение зависит от политик как нового документа, так и открывшего его документа, а также от того, был ли новый документ открыт в результате перехода или с помощью Window.open().

Синтаксис

Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Opener-Policy: noopener-allow-popups

Директивы

unsafe-none

Документ разрешает совместное использование своей группы контекста просмотра с любым другим документом, что может быть небезопасно. Эта директива позволяет отказаться от использования COOP для изоляции процессов документа. Это значение используется по умолчанию.

При переходах документы с unsafe-none всегда будут открывать документы в новой BCG и открываться в новой BCG, если только другой документ также не имеет unsafe-none (или не имеет значения директивы COOP).

При использовании Window.open() документы с unsafe-none всегда будут открывать документы с любым другим значением в новой BCG. Однако документы с unsafe-none можно открыть в той же BCG, если открывший их документ содержит директиву same-origin-allow-popups, noopener-allow-popups или unsafe-none. Документ с same-origin всегда откроет документ с unsafe-none в новой BCG.

same-origin

Документ разрешает загрузку в BCG, которые используют COOP и содержат только документы того же источника. Эта директива используется для обеспечения межсайтовой изоляции BCG.

Документы с same-origin будут открываться в той же BCG и открывать документы в той же BCG, только если оба документа имеют один и тот же источник и директиву same-origin.

same-origin-allow-popups

Эта директива похожа на директиву same-origin, но позволяет открывать документы с помощью Window.open() в той же BCG, если их значение COOP равно unsafe-none.

Директива используется для ослабления ограничения same-origin в сценариях интеграции, когда документу нужны преимущества межсайтовой изоляции, но также необходимо открывать доверенные документы из другого источника и сохранять на них ссылку. Например, при использовании межсайтового сервиса для OAuth или платежей.

Документ с этой директивой может открыть документ в той же BCG с помощью Window.open(), если его значение COOP равно unsafe-none. В этом случае не имеет значения, относится ли открытый документ к другому или тому же сайту.

В противном случае документы с same-origin-allow-popups будут открываться в той же BCG и открывать документы в той же BCG, только если оба документа имеют один и тот же источник и директиву same-origin-allow-popups.

noopener-allow-popups

Документы с этой директивой всегда открываются в новой BCG, за исключением случаев, когда они открыты переходом из документа, который также содержит noopener-allow-popups. Директива используется в случаях, когда необходимо изолировать на уровне процесса документы одного источника.

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

При переходах документ с этой директивой всегда будет открывать другие документы в новой BCG, если только они не имеют тот же источник и директиву noopener-allow-popups. При использовании Window.open() документ с этой директивой будет открывать документы в новой BCG, если только они не содержат unsafe-none; в этом случае не имеет значения, относятся ли они к тому же или другому сайту.

Описание

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

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

Переходы

При переходе между документами новый документ открывается в той же BCG, если у двух документов «совпадают политики COOP», в противном случае — в новой BCG.

Политики совпадают, если оба документа используют политику unsafe-none или если политики одинаковы, а документы имеют один и тот же источник.

В таблице ниже показано, как это правило влияет на то, будут ли документы открываться в той же или новой BCG при разных значениях директив.

Открытие с помощью Window.open()

При открытии документа с помощью Window.open() новый документ открывается в новой BCG согласно следующим правилам, которые проверяются по порядку:

1. Если для нового документа COOP установлен в noopener-allow-popups => открыть новый документ в новой BCG
2. Если для нового документа COOP установлен в unsafe-none, а для открывающего документа COOP установлен в same-origin-allow-popups или noopener-allow-popups => открыть новый документ в той же BCG
3. Если у нового и открывающего документов совпадают политики COOP => открыть новый документ в той же BCG
4. В противном случае открыть новый документ в новой BCG

В таблице ниже показано, как эти правила влияют на то, будут ли документы открываться в той же или новой BCG при разных значениях директив.

Примеры

Возможности, зависящие от межсайтовой изоляции

Некоторые возможности, например доступ к объектам SharedArrayBuffer или использование Performance.now() с таймерами без ограничения частоты, доступны только в том случае, если документ имеет межсайтовую изоляцию.

Чтобы использовать эти возможности в документе, необходимо установить для заголовка COOP значение same-origin, а для заголовка Cross-Origin-Embedder-Policy — значение require-corp (или credentialless). Кроме того, возможность не должна быть заблокирована политикой Permissions-Policy: cross-origin-isolated.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Свойства Window.crossOriginIsolated и WorkerGlobalScope.crossOriginIsolated позволяют проверить, имеет ли документ межсайтовую изоляцию, а следовательно, ограничен ли доступ к этим возможностям:

const myWorker = new Worker("worker.js");

if (crossOriginIsolated) {
  const buffer = new SharedArrayBuffer(16);
  myWorker.postMessage(buffer);
} else {
  const buffer = new ArrayBuffer(16);
  myWorker.postMessage(buffer);
}

Разрыв связи с открывшим документом

Представим гипотетический источник example.com, в котором размещены два совершенно разных приложения:

• Чат-приложение по адресу /chat, позволяющее любому пользователю связываться с другими пользователями и отправлять им сообщения.
• Приложение для управления паролями по адресу /passwords, в котором хранятся все пароли пользователя для разных сервисов.

Администраторы приложения «пароли» очень хотели бы гарантировать, что приложение «чат» не сможет напрямую управлять им с помощью скриптов, поскольку в этом приложении больше возможностей для XSS-атак. «Правильным» способом изолировать эти приложения было бы размещение их на разных источниках, но в некоторых случаях это невозможно, и по историческим, деловым причинам или причинам брендинга оба приложения должны находиться на одном источнике.

Заголовок Cross-Origin-Opener-Policy: noopener-allow-popups позволяет гарантировать, что документ не сможет управляться с помощью скриптов из документа, который его открыл.

Если example.com/passwords отдаётся с noopener-allow-popups, то WindowProxy, возвращаемое Window.open(), будет указывать, что окно закрыто (Window.closed равно true), поэтому открывший документ не сможет управлять приложением паролей с помощью скриптов:

const handle = window.open("example.com/passwords", "passwordTab");
if (windowProxy.closed) {
  // The new window is closed so it can't be scripted.
}

Обратите внимание, что одной этой меры недостаточно для обеспечения безопасности. Сайту также необходимо сделать следующее:

• Использовать Fetch Metadata, чтобы блокировать запросы того же источника к более чувствительному приложению, если эти запросы не являются запросами навигации.
• Убедиться, что для всех файлов cookie аутентификации установлен атрибут HttpOnly.
• Убедиться, что менее чувствительное приложение не устанавливает Service Worker для корневого уровня.
• Убедиться, что postMessage или BroadcastChannel более чувствительного приложения не раскрывают конфиденциальную информацию другим приложениям того же источника.
• Разместить страницу входа на отдельном источнике, поскольку автозаполнение менеджером паролей работает на основе источника.
• Учитывать, что браузер всё ещё может разместить более чувствительное приложение в том же процессе, что и менее чувствительное, подвергая его атакам типа Spectre.

Спецификации

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

См. также

• Cross-Origin-Embedder-Policy