Краткий справочник по заголовкам безопасности

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

Эйдзи Китамура
Артур Янц
Artur Janc
X GitHub
Мод Налпас

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

Рекомендуемые заголовки безопасности для веб-сайтов, обрабатывающих конфиденциальные данные пользователей:
Политика безопасности контента (CSP)
Доверенные типы
Рекомендуемые заголовки безопасности для всех веб-сайтов:
X-Content-Type-Options
X-Frame-Options
Политика межрегионального доступа к ресурсам (CORP)
Политика открытия межстрановых соединений (COOP)
HTTP Strict Transport Security (HSTS)
Заголовки безопасности для веб-сайтов с расширенными возможностями:
Междоменный обмен ресурсами (CORS)
Политика внедрения перекрестного происхождения (COEP)
Известные угрозы в интернете
Прежде чем углубляться в тему заголовков безопасности, изучите известные угрозы в интернете и причины, по которым вам может понадобиться использовать эти заголовки.

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

Защитите свой сайт от уязвимостей внедрения кода.

Уязвимости внедрения возникают, когда ненадежные данные, обрабатываемые вашим приложением, могут повлиять на его поведение и, как правило, привести к выполнению скриптов, управляемых злоумышленником. Наиболее распространенной уязвимостью, вызванной ошибками внедрения, является межсайтовый скриптинг (XSS) в различных его формах, включая отраженный XSS , хранимый XSS , XSS на основе DOM и другие варианты.

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

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

  • Используйте политику безопасности контента (CSP) , чтобы контролировать, какие скрипты могут быть выполнены вашим приложением, и снизить риск внедрения вредоносного кода.
  • Используйте доверенные типы (Trusted Types) для обеспечения проверки и очистки данных, передаваемых в опасные JavaScript API.
  • Используйте X-Content-Type-Options , чтобы предотвратить неправильное толкование браузером MIME-типов ресурсов вашего веб-сайта, что может привести к выполнению скриптов.

Изолируйте свой сайт от других веб-сайтов.

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

К распространенным уязвимостям, подрывающим веб-изоляцию, относятся кликджекинг , межсайтовая подделка запросов (CSRF), межсайтовое включение скриптов (XSSI) и различные межсайтовые утечки .

Книга "Post-Spectre Web Development" — отличное чтение, если вас интересуют эти заголовочные файлы.

Создайте мощный веб-сайт безопасно

Уязвимость Spectre делает любые данные, загруженные в одну и ту же группу контекстов просмотра, потенциально доступными для чтения, несмотря на политику ограничения доступа по одному источнику . Браузеры ограничивают функции, которые могут использовать эту уязвимость, за счет специальной среды, называемой « междоменная изоляция ». Благодаря междоменной изоляции можно использовать такие мощные функции, как SharedArrayBuffer .

Шифрование трафика на ваш сайт

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

Недостаточное шифрование может возникнуть в следующих случаях: неиспользование HTTPS, смешанный контент , установка файлов cookie без атрибута Secure (или префикса __Secure ) или нестрогая логика проверки CORS .

Политика безопасности контента (CSP)

Межсайтовый скриптинг (XSS) — это атака, при которой уязвимость на веб-сайте позволяет внедрить и выполнить вредоносный скрипт.

Content-Security-Policy обеспечивает дополнительный уровень защиты от XSS-атак, ограничивая выполнение скриптов на странице.

Рекомендуется включить строгий CSP, используя один из следующих способов:

  • Если вы генерируете HTML-страницы на сервере, используйте строгую политику конфиденциальности (CSP) на основе одноразовых чисел (nonce) .
  • Если ваш HTML-код должен отображаться статически или кэшироваться, например, если это одностраничное приложение, используйте строгую политику конфиденциальности на основе хешей .

Пример использования: CSP на основе одноразового кода (nonce).

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
Как использовать CSP

1. Используйте строгую CSP на основе nonce {: #nonce-based-csp}

Если вы генерируете HTML-страницы на сервере, используйте строгую политику конфиденциальности (CSP) на основе одноразовых чисел (nonce) .

Для каждого запроса на стороне сервера генерируйте новое значение nonce скрипта и устанавливайте следующий заголовок:

файл конфигурации сервера

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

В HTML для загрузки скриптов установите атрибут nonce для всех тегов <script> на одну и ту же строку {RANDOM1} .

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Google Photos — хороший пример строгой политики конфиденциальности на основе одноразовых чисел (nonce). Используйте инструменты разработчика, чтобы посмотреть, как это используется.

2. Используйте строгую CSP на основе хеширования {: #hash-based-csp}

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

файл конфигурации сервера

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

В HTML для применения политики на основе хеширования вам потребуется встраивать скрипты непосредственно в код, поскольку большинство браузеров не поддерживают хеширование внешних скриптов .

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

Для загрузки внешних скриптов ознакомьтесь с разделом «Динамическая загрузка исходных скриптов» в подразделе «Вариант B: Хэш-заголовок ответа CSP» .

CSP Evaluator — это хороший инструмент для оценки вашей CSP, а также хороший пример строгой CSP на основе nonce. Используйте DevTools, чтобы посмотреть, как его использовать.

Поддерживаемые браузеры

Другие важные моменты, касающиеся CSP.

Узнать больше

Доверенные типы

XSS на основе DOM — это атака, при которой вредоносные данные передаются в приемник, поддерживающий динамическое выполнение кода, например, с помощью eval() или .innerHTML .

Доверенные типы предоставляют инструменты для написания, проверки безопасности и поддержки приложений, защищенных от DOM XSS. Их можно включить через CSP , и они делают JavaScript-код безопасным по умолчанию, ограничивая опасные веб-API возможностью приема только специального объекта — доверенного типа.

Для создания таких объектов можно определить политики безопасности, которые гарантируют последовательное применение правил безопасности (таких как экранирование или очистка) до записи данных в DOM. В этом случае эти политики являются единственными местами в коде, которые потенциально могут привести к DOM XSS-атакам.

Примеры использования

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
Как использовать доверенные типы

  1. Внедрение протокола CSP и заголовка Trusted Types для опасных DOM-приемников:

    Content-Security-Policy: require-trusted-types-for 'script'

    В настоящее время единственным допустимым значением для директивы require-trusted-types-for является 'script' .

    Разумеется, вы можете комбинировать доверенные типы с другими директивами CSP:

Объединение CSP на основе одноразовых чисел, описанного выше, с доверенными типами: 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;

 <aside class="note"><b>Примечание:</b> Вы можете ограничить количество разрешенных имен политик доверенных типов, установив дополнительную директиву <code>trusted-types</code> (например, <code>trusted-types myPolicy</code>). Однако это не является обязательным требованием. </aside>

  1. Определите политику

    Политика: 

    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

  2. Примените политику

    При записи данных в DOM используйте эту политику: 

    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;

    При использовании require-trusted-types-for 'script' , использование доверенного типа является обязательным. Использование любого опасного DOM API со строкой приведет к ошибке.

Поддерживаемые браузеры

Узнать больше

X-Content-Type-Options

Когда вредоносный HTML-документ загружается с вашего домена (например, если изображение, загруженное в фотосервис, содержит допустимую HTML-разметку), некоторые браузеры будут рассматривать его как активный документ и позволять ему выполнять скрипты в контексте приложения, что приведет к уязвимости межсайтового скриптинга .

X-Content-Type-Options: nosniff предотвращает это, сообщая браузеру, что MIME-тип, указанный в заголовке Content-Type для данного ответа, является правильным. Этот заголовок рекомендуется использовать для всех ваших ресурсов .

Пример использования 

X-Content-Type-Options: nosniff
Как использовать X-Content-Type-Options

Рекомендуется использовать X-Content-Type-Options: nosniff для всех ресурсов, предоставляемых вашим сервером, вместе с правильным заголовком Content-Type .

X-Content-Type-Options: nosniff

Примеры заголовков, отправляемых вместе с HTML-документом. 

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

Поддерживаемые браузеры

Browser Support

  • Chrome: 64.
  • Край: 12.
  • Firefox: 50.
  • Сафари: 11.

Source

Узнать больше

X-Frame-Options

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

X-Frame-Options указывает, разрешается ли браузеру отображать страницу в <frame> , <iframe> , <embed> или <object> . Всем документам рекомендуется отправлять этот заголовок, чтобы указать, разрешается ли их встраивание в другие документы.

Пример использования 

X-Frame-Options: DENY
Как использовать X-Frame-Options

Для всех документов, не предназначенных для встраивания, следует использовать заголовок X-Frame-Options .

В этой демонстрации вы можете проверить, как следующие настройки влияют на загрузку iframe. Измените значение в выпадающем меню X-Frame-Options и нажмите кнопку «Перезагрузить iframe» .

Защищает ваш веб-сайт от встраивания другими веб-сайтами.

Отрицаем внедрение данных в другие документы.

X-Frame-Options: DENY
X-Frame-Options: DENY

Защищает ваш веб-сайт от встраивания с сайтов других доменов.

Разрешить встраивание только документов того же источника. 

X-Frame-Options: SAMEORIGIN

Поддерживаемые браузеры

Browser Support

  • Chrome: 4.
  • Край: 12.
  • Firefox: 4.
  • Сафари: 4.

Source

Узнать больше

Политика межрегионального доступа к ресурсам (CORP)

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

Заголовок Cross-Origin-Resource-Policy снижает этот риск, указывая набор веб-сайтов, с которых может быть загружен данный ресурс. Заголовок принимает одно из трех значений: same-origin , same-site и cross-origin . Всем ресурсам рекомендуется отправлять этот заголовок, чтобы указать, разрешают ли они загрузку с других веб-сайтов.

Пример использования 

Cross-Origin-Resource-Policy: same-origin
Как использовать CORP

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

В этом демонстрационном примере вы можете проверить, как следующие настройки влияют на загрузку ресурсов в среде с Cross-Origin-Embedder-Policy: require-corp . Измените значение в раскрывающемся меню Cross-Origin-Resource-Policy и нажмите кнопку «Перезагрузить iframe» или «Перезагрузить изображение» , чтобы увидеть результат.

Разрешить загрузку ресурсов cross-origin

Рекомендуется, чтобы сервисы, подобные CDN, применяли cross-origin к ресурсам (поскольку они обычно загружаются страницами из других источников), если только они уже не обслуживаются через CORS , который имеет аналогичный эффект.

Cross-Origin-Resource-Policy: cross-origin
Cross-Origin-Resource-Policy: cross-origin

Ограничьте загрузку ресурсов из same-origin

same-origin следует применять к ресурсам, предназначенным для загрузки только страницами с тем же источником. Это следует применять к ресурсам, содержащим конфиденциальную информацию о пользователе, или к ответам API, которые предназначены для вызова только с того же источника.

Имейте в виду, что ресурсы с этим заголовком по-прежнему могут загружаться напрямую, например, при переходе по URL-адресу в новом окне браузера. Политика межсайтовой защиты ресурсов (Cross-Origin Resource Policy) защищает ресурс только от встраивания другими веб-сайтами.

Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

Ограничьте загрузку ресурсов с same-site

Рекомендуется применять same-site к ресурсам, аналогичным описанным выше, но предназначенным для загрузки другими поддоменами вашего сайта.

Политика межсайтовых ресурсов: соответствие одному сайту
Cross-Origin-Resource-Policy: same-site

Поддерживаемые браузеры

Browser Support

  • Chrome: 73.
  • Край: 79.
  • Firefox: 74.
  • Сафари: 12.

Source

Узнать больше

Политика открытия межстрановых соединений (COOP)

Веб-сайт злоумышленника может открывать другой сайт во всплывающем окне, чтобы получить информацию о нём, используя уязвимости межсайтовых утечек (XSS) . В некоторых случаях это также может позволить использовать атаки по побочным каналам, основанные на уязвимости Spectre .

Заголовок Cross-Origin-Opener-Policy позволяет документу изолироваться от окон, открываемых из других источников через window.open() или ссылку с target="_blank" без rel="noopener" . В результате любой пользователь, открывающий документ из другого источника, не будет иметь на него ссылки и не сможет с ним взаимодействовать.

Пример использования 

Cross-Origin-Opener-Policy: same-origin-allow-popups
Как использовать COOP

В этой демонстрации вы можете проверить, как следующие настройки влияют на взаимодействие с всплывающим окном, открываемым из другого источника. Измените параметры в раскрывающемся меню Cross-Origin-Opener-Policy как для документа, так и для всплывающего окна, нажмите кнопку « Открыть всплывающее окно», а затем нажмите «Отправить postMessage», чтобы проверить, действительно ли сообщение доставлено.

Изолировать документ от окон, находящихся в разных источниках.

Установка параметра same-origin изолирует документ от окон документов, находящихся в других источниках.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin

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

Параметр same-origin-allow-popups позволяет документу сохранять ссылку на свои всплывающие окна, если только в COOP не задан параметр same-origin или same-origin-allow-popups . Это означает, что same-origin-allow-popups может защитить документ от ссылок при открытии в виде всплывающего окна, но при этом позволить ему взаимодействовать со своими собственными всплывающими окнами.

Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin-allow-popups

Разрешить ссылки на документ в окнах Windows, работающих в разных источниках.

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

Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: unsafe-none

Шаблоны отчетов, несовместимые с COOP

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

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

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

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

Поддерживаемые браузеры

Browser Support

  • Chrome: 83.
  • Край: 83.
  • Firefox: 79.
  • Сафари: 15.2.

Source

Узнать больше

Междоменный обмен ресурсами (CORS)

В отличие от других элементов этой статьи, протокол CORS (Cross-Origin Resource Sharing) — это не заголовок, а механизм браузера, который запрашивает и разрешает доступ к ресурсам из других источников.

По умолчанию браузеры применяют политику одного источника (Same-origin policy) , чтобы предотвратить доступ веб-страницы к ресурсам из других источников. Например, когда загружается изображение из другого источника, даже если оно отображается на веб-странице визуально, JavaScript на странице не имеет доступа к данным изображения. Поставщик ресурсов может ослабить ограничения и разрешить другим веб-сайтам читать ресурс, включив CORS.

Пример использования 

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Как использовать CORS

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

Критерии для простой просьбы:

  • Метод — GET , HEAD или POST .
  • Пользовательские заголовки включают только Accept , Accept-Language , Content-Language и Content-Type .
  • Content-Type может быть application/x-www-form-urlencoded , multipart/form-data или text/plain .

Все остальные запросы классифицируются как предварительные. Для получения более подробной информации см. статью «Cross-Origin Resource Sharing (CORS) - HTTP | MDN» .

Простая просьба

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

Пример заголовка запроса 

Get / HTTP/1.1
Origin: https://example.com

Пример заголовка ответа 

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com указывает, что https://example.com может получить доступ к содержимому ответа. Ресурсы, предназначенные для чтения любым сайтом, могут установить этот заголовок в значение * , в этом случае браузеру потребуется только отправить запрос без учетных данных .
  • Access-Control-Allow-Credentials: true указывает, что запросы, содержащие учетные данные (cookie), разрешают загрузку ресурса. В противном случае аутентифицированные запросы будут отклонены, даже если источник запроса указан в заголовке Access-Control-Allow-Origin .

В этой демонстрации вы можете попробовать, как простой запрос влияет на загрузку ресурсов в среде с Cross-Origin-Embedder-Policy: require-corp . Установите флажок Cross-Origin Resource Sharing и нажмите кнопку Reload the image , чтобы увидеть эффект.

Предварительно обработанные запросы

Предварительный запрос предваряется запросом OPTIONS для проверки разрешения на отправку последующего запроса.

Пример заголовка запроса 

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST позволяет отправлять следующие запросы с использованием метода POST .
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type позволяют запрашивающей стороне установить заголовки HTTP X-PINGOTHER и Content-Type в последующем запросе.

Примеры заголовков ответа 

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS указывает, что последующие запросы могут выполняться с использованием методов POST , GET и OPTIONS .
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type указывают, что последующие запросы могут включать заголовки X-PINGOTHER и Content-Type .
  • Access-Control-Max-Age: 86400 указывает, что результат предварительного запроса может храниться в кэше в течение 86400 секунд.

Поддерживаемые браузеры

Browser Support

  • Chrome: 4.
  • Край: 12.
  • Firefox: 3.5.
  • Сафари: 4.

Source

Узнать больше

Политика внедрения перекрестного происхождения (COEP)

Чтобы уменьшить вероятность кражи междоменных ресурсов при атаках с использованием уязвимости Spectre , такие функции, как SharedArrayBuffer или performance.measureUserAgentSpecificMemory() по умолчанию отключены.

Cross-Origin-Embedder-Policy: require-corp предотвращает загрузку ресурсов из разных источников, таких как изображения, скрипты, таблицы стилей, iframe и другие, документами и рабочими процессами, если эти ресурсы явно не настроены на загрузку через заголовки CORS или CORP . COEP можно комбинировать с Cross-Origin-Opener-Policy , чтобы включить изоляцию документа от других источников .

Используйте Cross-Origin-Embedder-Policy: require-corp если хотите включить междоменную изоляцию для вашего документа.

Пример использования 

Cross-Origin-Embedder-Policy: require-corp
Как использовать COEP

Примеры использования

Заголовок COEP принимает одно значение require-corp . Отправляя этот заголовок, вы можете указать браузеру блокировать загрузку ресурсов, которые не дали согласия на использование CORS или CORP .

Как работает COEP

В этой демонстрации вы можете попробовать, как следующие настройки влияют на загрузку ресурсов. Измените параметры в раскрывающемся меню Cross-Origin-Embedder-Policy , в раскрывающемся меню Cross-Origin-Resource-Policy , установите флажок « Только отчет» и т.д., чтобы увидеть, как они влияют на загрузку ресурсов. Также откройте демонстрационный пример конечной точки отчетности , чтобы проверить, отображаются ли заблокированные ресурсы.

Включить междоменную изоляцию

Включите междоменную изоляцию , отправив Cross-Origin-Embedder-Policy: require-corp вместе с Cross-Origin-Opener-Policy: same-origin . 

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

Сообщайте о ресурсах, несовместимых с COEP.

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

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP также поддерживает режим только для отчетов, поэтому вы можете получать отчеты, не блокируя при этом загрузку ресурсов. 

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

Поддерживаемые браузеры

Browser Support

  • Chrome: 83.
  • Край: 83.
  • Firefox: 79.
  • Сафари: 15.2.

Source

Узнать больше

HTTP Strict Transport Security (HSTS)

Передача данных по обычному HTTP-соединению не шифруется, что делает передаваемые данные доступными для злоумышленников, осуществляющих прослушивание на сетевом уровне.

Заголовок Strict-Transport-Security сообщает браузеру, что он никогда не должен загружать сайт по протоколу HTTP, а вместо этого должен использовать HTTPS. После установки этого заголовка браузер будет использовать HTTPS вместо HTTP для доступа к домену без перенаправления в течение времени, указанного в заголовке.

Пример использования 

Strict-Transport-Security: max-age=31536000
Как использовать HSTS

Все веб-сайты, переходящие с HTTP на HTTPS, должны отвечать заголовком Strict-Transport-Security при получении запроса по протоколу HTTP. 

Strict-Transport-Security: max-age=31536000

Поддерживаемые браузеры

Browser Support

  • Chrome: 4.
  • Край: 12.
  • Firefox: 4.
  • Сафари: 7.

Source

Узнать больше

Дополнительная информация