Ресурсы с перекрестным происхождением, обслуживаемые третьими сторонами, часто не содержат адекватных заголовков CORP. Если их можно запросить без учетных данных, теперь вы можете включить изоляцию между источниками, пометив их как таковые.
Мы добавили новое значение политики внедрения перекрестного происхождения (COEP) credentialless , которое позволяет браузеру загружать ресурсы перекрестного происхождения, которые не используют политику ресурсов перекрестного происхождения (CORP), путем отправки запроса без учетных данных, например файлов cookie. . Это помогает разработчикам легче применять изоляцию между источниками.
Зачем нам нужна изоляция между источниками
Некоторые веб-API повышают риск атак по побочным каналам, например Spectre . Чтобы снизить этот риск, браузеры предлагают изолированную среду на основе согласия, называемую изоляцией между источниками . В изолированном состоянии между источниками веб-страница может использовать привилегированные функции, включая SharedArrayBuffer , performance.measureUserAgentSpecificMemory() и высокоточные таймеры с лучшим разрешением , изолируя источник от других, если они не включены.
Веб-страница должна отправить два HTTP-заголовка, чтобы включить изоляцию между источниками:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
В изолированном состоянии между источниками все ресурсы между источниками должны обслуживаться с помощью CORS или устанавливать заголовок Cross-Origin-Resource-Policy для загрузки.
Проблемы с включением изоляции между источниками
Хотя изоляция между источниками повышает безопасность веб-страниц и дает возможность использовать мощные функции, ее развертывание может быть затруднено . Одной из самых больших проблем является требование включить CORS или CORP для всех ресурсов с перекрестным происхождением. Ресурсы без этих заголовков не будут загружаться браузером на изолированной странице с перекрестным происхождением.
Эти ресурсы с перекрестным происхождением обычно обслуживаются третьими сторонами, которым может быть непросто добавить необходимые заголовки.
Но что, если мы знаем, что ресурс достаточно безопасен для загрузки? Фактически, единственные ресурсы, которые подвергаются риску, — это те, которые запрашиваются с учетными данными, поскольку они потенциально содержат конфиденциальную информацию, которую злоумышленник не может загрузить самостоятельно. Это означает, что ресурсы, которые можно запросить без учетных данных, общедоступны и их можно безопасно загружать.
credentialless спешит на помощь
Вот тут-то и появляется COEP: credentialless . credentialless — это новое значение для заголовка Cross-Origin-Embedder-Policy . Подобно require-corp , он может включать изоляцию между источниками, но вместо требования заголовка CORP:cross-origin для запросов no-cors между источниками они отправляются без учетных данных (например, файлов cookie).
Альтернативно вы сможете включить изоляцию между источниками с помощью следующих двух заголовков:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
Это означает, что запрошенный междоменный сервер не сможет ответить конфиденциальным ресурсом, и запрашивающая сторона всегда может предположить, что ответ содержит только общедоступную информацию.
Это также соответствует плану браузеров по поэтапному отказу от сторонних файлов cookie .
Демо
Вы можете попробовать различные варианты заголовка в этой демонстрации: https://cross-origin-isolation.glitch.me
Часто задаваемые вопросы
Могу ли я отправить запрос с учетными данными в среде credentialless ?
Конечно, за счет изменения режима запроса, требующего проверки CORS для ответа. Для тегов HTML, таких как <audio> , <img> , <link> , <script> и <video> , просто добавьте crossorigin="use-credentials" явно, чтобы сообщить браузеру о необходимости отправки запросов с учетными данными.
Например, даже если документ на https://www.example.com имеет заголовок Cross-Origin-Embedder-Policy: credentialless , <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> отправит запрос с учетными данными.
Для API fetch() можно использовать request.mode = 'cors' .
Если COEP: credentialless , каким образом COEP: require-corp все еще полезен для моего веб-сайта?
COEP: require-corp не требует, чтобы вы вручную переключали режим запроса на CORS, если файлы cookie необходимы для некоторых подресурсов с перекрестным происхождением.
Могу ли я также загружать iframe из разных источников без специальных заголовков в среде credentialless ?
Нет. Загрузка iframe из разных источников в среде credentialless по-прежнему требует тех же условий, что и require-corp . Документы iframe должны обслуживаться с двумя заголовками:
-
Cross-Origin-Embedder-Policy: credentialless(илиrequire-corp) -
Cross-Origin-Resource-Policy: cross-origin
Хорошей новостью является то, что продолжается дискуссия о том, чтобы разрешить загрузку iframe с перекрестным происхождением без этих заголовков, указав iframes crossorigin="anonymous" . Это позволит загружать iframe из разных источников без заголовков, но без учетных данных.
Будет ли эта функция принята другими браузерами?
- Проблема с отслеживанием Firefox
- Webkit Запрос позиции: нет сигнала
- W3C TAG Запрос позиции: Ожидается
Что будет дальше
Есть два дополнительных обновления, призванных смягчить другие проблемы, связанные с изоляцией между источниками:
Те, кто зарегистрировался для участия в пробной версии Chrome Origin, чтобы продлить изменение SharedArrayBuffer из-за вышеупомянутых препятствий, могут задаться вопросом, когда оно будет прекращено. Первоначально мы объявили, что поддержка этой функции будет прекращена в Chrome 96, но мы решили перенести это на Chrome 106.
Ресурсы
- Создание вашего веб-сайта «изолированного от перекрестного происхождения» с помощью COOP и COEP
- Почему вам нужна «изоляция перекрестного происхождения» для мощных функций
- Руководство по включению изоляции между источниками
- Обновления SharedArrayBuffer в Android Chrome 88 и Desktop Chrome 92
Фото Мартина Адамса на Unsplash