COOP, COEP и CORP: изоляция страницы за reverse proxy

Основная идея

Cross-origin isolation возникает из согласованной политики верхнего документа и загружаемых ресурсов. COOP управляет browsing context group, COEP требует допустимое встраивание, а CORP даёт ресурсу явную политику. Один заголовок на HTML не завершает настройку.

Тему «COOP, COEP и CORP: изоляция страницы за reverse proxy» лучше начинать с модели угроз: что именно защищаем, от кого и на каком участке пути. Логин ограничивает доступ к прокси, TLS защищает содержимое соединения с сайтом, а белый список ограничивает источник подключения. Эти меры дополняют друг друга, но ни одна из них не делает опасную автоматизацию безопасной сама по себе.

Что подтверждает первичный источник

Проверяем согласованность заголовков документа и ресурсов, а затем намеренно ломаем одну CDN-зависимость.

Первичный источник «WHATWG Cross-origin isolation, MDN COOP, MDN COEP, MDN CORP, WHATWG Fetch» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

Страница использует собственный worker и два ресурса с отдельного тестового origin. Установите COOP same-origin и выбранный режим COEP, выдайте нужные CORP/CORS поля. Проверьте новый и старый cache entry, popup opener и worker. Затем удалите поле у одного ресурса и подтвердите ожидаемый browser error.

Проверка шаг за шагом

Инвентаризируйте script, worker, image и font origins своей страницы. Включите заголовки на staging и проверяйте crossOriginIsolated, загрузку каждого ресурса и opener behavior. Proxy должен сохранять поля и не отдавать старую версию из кэша.

Проводите опыт на тестовом аккаунте и домене, где проверка разрешена. Создайте отдельные реквизиты с минимальными правами, задайте короткий срок их жизни и заранее определите способ отзыва. Затем проверьте нормальный вход, отказ с неверным секретом и отказ из неразрешённой сети. Три результата должны различаться и не раскрывать пароль в тексте ошибки.

Просмотрите не только интерфейс, но и журналы приложения, историю команд, HAR-файлы и сообщения поддержки. Строка подключения может попасть в URL, аргументы процесса, историю терминала или снимок экрана. После проверки смените временный пароль и удалите тестовые материалы, которые содержат чувствительные заголовки или cookies.

• Составить graph ресурсов
• Включить COOP/COEP на staging
• Проверить CORP/CORS и кэш
• Сломать одну зависимость

Какие данные сохранить

Храните response headers HTML/ресурсов, crossOriginIsolated, resource URL origin, cache age, console category, worker result и popup relationship без пользовательских данных.

Безопасный отчёт хранит идентификатор проверки, время, результат и применённую политику. В нём не должно быть пароля, cookie, токена, полного URL с секретом или открытого файла состояния браузера. Если нужно подтвердить ротацию реквизитов, записывают событие и последние четыре условных символа, а не прежнее и новое значение целиком.

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

Как читать результат

Отрицательный тест удаляет CORP/CORS у одной тестовой CDN-зависимости и ожидает точный блок. Если приложение просто отключает COEP ради восстановления, изоляция исчезает; решение должно исправлять конкретный ресурс.

Политика относится к браузеру и origin graph, а не к анонимности трафика. Старые браузеры и сторонние ресурсы могут не поддержать выбранную конфигурацию.

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

Разбор рабочего решения

Для «COOP, COEP и CORP: изоляция страницы за reverse proxy» составьте реестр доступа ещё до настройки клиента. Для каждого подключения запишите владельца, назначение, срок, разрешённую сеть и способ отзыва. Общая строка для нескольких сотрудников лишает аудит смысла: после утечки невозможно определить источник и выборочно закрыть доступ. Раздельные реквизиты также позволяют сначала выпустить замену, проверить её на одном безопасном запросе и только затем отозвать старый секрет без простоя процесса.

Негативная проверка обязательна. После успешного входа попробуйте старые реквизиты, неразрешённый IP и заведомо неверное имя назначения. Система должна отказать на ожидаемом этапе и не раскрыть секрет в сообщении. Затем просмотрите браузерную историю, журнал запуска, CI-вывод и вложения обращения в поддержку. Если полная строка подключения попала хотя бы в одно из этих мест, считайте её раскрытой и смените.

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

Типичные ошибки

Опасные упрощения повторяются: отключение проверки сертификата, общий пароль на всю команду, слишком широкий CIDR и отправка прокси-URL в чат. Такие решения ускоряют первый запуск, но лишают систему границ доверия. Правильное исправление — восстановить проверку, выпустить отдельный секрет, сузить доступ и проверить отзыв старых данных.

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

Критерии внедрения и сопровождение

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

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

Рабочий регламент

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

• Определены данные и нарушитель
• Использован отдельный тестовый доступ
• TLS-проверка не отключена
• Логи просмотрены на утечки
• Есть процедура отзыва
• Проверен отказ вне разрешённых условий