Политика одного источника и изоляция сайтов

Политика одного источника ограничивает то, как документ или скрипт читает и изменяет другой origin.

Origin состоит из схемы, хоста и порта. Изменение любой части создаёт другую границу.

Политика ограничивает видимые скрипту данные и связи документов; это не сетевой экран и не замена серверной авторизации.

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

Она уменьшает последствия компрометации renderer и помогает ограничить межсайтовые данные, но не решает, имеет ли API право принять запрос. Поэтому наблюдение браузера, ответ сервера и результат приложения нужно записывать отдельно.

Как определяется origin

Модель origin WHATWG использует схему, хост и порт для обычного сетевого документа. https://shop.example.test:443 обычно эквивалентен адресу с портом по умолчанию, а другой протокол, хост или порт создаёт другую границу.

Адреса https://shop.example.test, https://app.example.test и https://cdn.example.test могут принадлежать одной организации, но всё равно задают разные origin. Тесты должны фиксировать итоговый location.origin после всех перенаправлений.

Некоторые документы имеют непрозрачный origin: это возможно для sandboxed iframe, data: и некоторых blob: URL. Нельзя выводить доверие из знакомого имени хоста, сертификата или владения родительским доменом.

Cookies, хранилища, разрешения и фоновые обработчики используют связанные, но не одинаковые правила. В отчёте указывайте, какое хранилище состояния проверялось.

Сравнение origin должно быть явным утверждением. Для сообщения из другого окна сравните event.origin с ожидаемым значением, проверьте схему данных и состояние операции. Это доказывает источник сообщения, но не доказывает авторизацию удалённого приложения.

Что разрешает политика одного источника

Справочник MDN описывает общий принцип: скрипт одного origin ограниченно получает DOM и данные другого origin. Cross-origin скрипт может навигировать окно или отправить форму, но не может произвольно читать DOM и байты ответа. Возможность зависит от конкретного API.

Cross-origin запрос может дойти до сервера и получить 200, пока Fetch скрывает ответ от скрипта без подходящего CORS. CORS разрешает чтение выбранного ответа, но не выдаёт роль пользователю и не делает endpoint надёжным. Для границы чтения ответа используйте руководство CORS.

Окна и frames имеют ограниченные связи. Для postMessage проверяйте event.origin, по возможности event.source и форму сообщения; при отправке задавайте конкретный target origin. Встраивание cross-origin страницы не даёт родителю права читать её DOM.

Встроенный контент и обмен сообщениями

Сначала определите parent и child origin после redirect, затем нужную операцию: отображение, навигацию, форму, сообщение, чтение ответа или DOM. После этого отдельно запишите правило браузера и проверку авторизации приложения. Для каждого frame задайте границу владения и доверия; политика разрешений и разрешение пользователя проверяются отдельно.

Связь или операция	Наблюдение браузера	Безопасный вывод
Доступ к DOM same-origin	Совпадают схема, хост и порт	Код всё равно проверяет состояние и права
Отображение cross-origin frame	Frame загрузился и сообщил итоговый origin	Отображение не даёт доступа к DOM
Чтение cross-origin ответа	Режим Fetch и CORS headers	Чтение не равно авторизации
Сообщение окна	Ожидаемые origin, source и schema	Origin проверяется вместе с данными сообщения
Изоляция сайта	Контекст браузера и объявленная сборка	Разделение процессов не доказывает безопасность приложения

Redirect может изменить итоговый origin и поведение cookies, хранилищ и CORS. document.domain не следует использовать как новый план интеграции; выбирайте явные сообщения или серверный API с обычной авторизацией.

Для каждого встроенного сценария заранее задайте владельца frame, допустимый target origin и версию схемы сообщения. Это облегчает замену старого доступа к DOM на явный канал сообщений и не превращает знакомый домен в автоматическое доказательство доверия.

Что добавляет изоляция сайтов

Обзор Chromium описывает изоляцию сайтов как защиту, разделяющую страницы в пространствах выполнения. Site шире origin в некоторых правилах платформы: два поддомена могут быть разными origin, но одним site. Распределение процессов зависит от платформы, памяти, версии браузера и отношений документов.

Изоляция уменьшает объём межсайтовых данных при ошибке безопасности renderer, но не превращает процесс в учётную запись операционной системы. Сервер по-прежнему аутентифицирует запрос, проверяет владельца ресурса, CSRF и переходы состояния. COOP и COEP могут менять связи окон, но остаются отдельными от same-origin policy.

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

Группы browsing context и связи opener также влияют на изоляцию. Окно, открытое между сайтами, может иметь другие отношения скриптов, а COOP и COEP меняют связи окон и загрузку ресурсов. Эти заголовки нужно проверять отдельно от решения same-origin и фиксировать вместе с итоговым поведением страницы.

Детерминированный fixture политики

Ниже приведён небольшой owned fixture. Он создаёт control и candidate, проверяет origin сообщения и показывает результат в output; он не читает чужие данные и не отправляет учётные данные.

async function checkOriginBoundary({ frameUrl, expectedOrigin, expectedMessage }) {
  const frame = document.createElement('iframe');
  const output = document.createElement('output');
  output.setAttribute('aria-live', 'polite');
  frame.src = frameUrl;
  window.addEventListener(
    'message',
    event => {
      if (event.origin !== expectedOrigin) return (output.textContent = 'UNKNOWN');
      output.textContent = event.data === expectedMessage ? 'ALLOWED' : 'REJECTED';
    },
    { once: true }
  );
  document.body.append(frame, output);
  await new Promise(resolve => setTimeout(resolve, 5000));
  return output.textContent || 'TIMEOUT';
}

await checkOriginBoundary({
  frameUrl: 'https://owned-child.example.test/fixture',
  expectedOrigin: 'https://owned-child.example.test',
  expectedMessage: 'owned-fixture-ready',
});

Control должен сообщить ожидаемый origin и корректное сообщение; candidate должен получить отдельный результат отказа. Если navigation, frame или status не готовы, возвращайте UNKNOWN или TIMEOUT, а не утверждение о политике. Сохраняйте итоговый origin, версию браузера, request log и состояние приложения.

Развёртывание, наблюдение и откат

Сначала составьте inventory всех узлов приложения, ресурсов и удостоверений. Запустите control и candidate в staging с окончательными именами, перенаправлениями и заголовками, затем проверьте окна входа, оплаты, frames и загрузки. После изменения CDN, поставщика удостоверений или версии браузера повторяйте тот же сценарий в новом контексте.

Откат должен вернуть прежнее сочетание приложения и политики, а не просто удалить assertion. Храните прежние headers, redirect map и конфигурацию frame. Не расширяйте allowlist origin и не принимайте произвольные origin сообщений ради зелёного теста. Сохраняйте HTTPS, authentication и authorization при откате.

Что может проверить BotBrowser

BotBrowser поддерживает авторизованный запуск собственных control и candidate fixture в изолированных браузерных контекстах и сравнение видимых результатов на объявленной сборке. Это подтверждается документацией multi-account isolation. BotBrowser не меняет origin, не обходит policy, не предоставляет серверную авторизацию и не доказывает завершение удалённой бизнес-операции. Ограничение важно: BotBrowser не настраивает чужой API и не превращает наблюдение процесса в гарантию приложения. Ответственность за server headers, authentication, authorization, CDN и application state остаётся у их владельцев. Автор: Команда BotBrowser.

Для связанных границ см. руководство по CORS, руководство по cross-origin isolation и руководство по хранилищам браузера. Они объясняют разделение состояния, читаемость ответа и isolation headers, тогда как здесь рассматриваются identity origin и доступ скрипта.

При диагностике начинайте с inventory origin и итогового URL, а не с догадки о процессе браузера. Для каждого шага храните одну наблюдаемую проверку и один вывод, который она не доказывает.

Для примера используйте synthetic адреса из fixture; они не обозначают реальные сервисы.

Owned fixture должен использовать synthetic данные, короткие тайм-ауты и новый browser context. Реальные cookies, аккаунты и приватные ответы в такой проверке не нужны.

В отчёте полезно разделять network error, timeout, policy rejection и application rejection. Это не позволяет исправлять заголовок браузера, когда настоящая причина находится в серверном маршруте.

Для сообщений между окнами фиксируйте sender, target origin и версию schema. Не принимайте сообщение только потому, что оно пришло из знакомого домена.

Перед публикацией изменения сравните control и candidate на одной сборке браузера. Если меняются redirect или CDN, повторите обе стороны и сохраните headers.

На стороне приложения проверяйте authorization и переход состояния независимо от того, разрешил ли браузер чтение ответа.

На стороне платформы описывайте ограничения процесса как наблюдение конкретной сборки, а не как универсальную гарантию для всех браузеров.

Sources

• WHATWG HTML: Origins
• MDN: Same-origin policy
• Chromium: Site isolation
• MDN: Window.postMessage
• BotBrowser: Multi-account isolation