Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

Руководства по безопасности

#заголовки безопасности#CSP#HSTS#XSS#настройка#веб-сервер

Как выбрать заголовки безопасности: что ещё нужно, что устарело и что вредит

Многие списки заголовков безопасности давно не обновлялись и советуют уже ненужные заголовки. MDN помечает X-XSS-Protection как устаревший и нестандартный и предупреждает, что он может создавать XSS-уязвимости на безопасных сайтах. Какие заголовки ставить сегодня, а какие убрать.

Опубликовано 2026-09-05 Обновлено 2026-10-04 Последняя проверка 2026-09-05 7 мин чтения

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

① Шесть, которые стоит ставить сегодня

Наш сканер заголовков безопасности оценивает именно по этим шести. Устаревшие заголовки намеренно исключены.

Шесть заголовков и за что отвечает каждый
Content-Security-Policy
Объявляет, откуда можно загружать скрипты и ресурсы. Главная мера, которая сужает возможности XSS. Его директива frame-ancestors также управляет встраиванием
Strict-Transport-Security
Говорит браузеру всегда возвращаться по HTTPS и закрывает первый незашифрованный запрос (max-age плюс includeSubDomains)
X-Frame-Options
Запрещает встраивание во фреймы на других сайтах — защита от кликджекинга. На практике ставится вместе с frame-ancestors из CSP
X-Content-Type-Options
nosniff. Не даёт браузеру угадывать тип по содержимому, что уменьшает случаи, когда загруженный файл интерпретируется не так, как должен
Referrer-Policy
Ограничивает передаваемый дальше referrer и уменьшает утечку того, что оказалось в URL (исходя из того, что секретов в URL вы и так не кладёте)
Permissions-Policy
Отключает возможности браузера по умолчанию — камеру, микрофон, геолокацию. Закройте то, чем не пользуетесь

Порядок важен: начните с того, что ничего не сломает

X-Content-Type-Options, X-Frame-Options, Referrer-Policy и Permissions-Policy надёжны и вряд ли нарушат отображение, поэтому их можно добавить первыми. Strict-Transport-Security стоит отложить, пока HTTPS не заработает на всех путях: браузеры его запоминают, и откатить его трудно.

CSP — последним и постепенно. Он затрагивает больше всего функций, и если сразу сделать его строгим, нужные функции сломаются. Собирайте его в конструкторе CSP.

② Что уже не нужно

Expect-CT: в основном устарел с июня 2021 года

MDN помечает этот заголовок как Deprecated и поясняет, что его реализовали только Google Chrome и другие браузеры на Chromium, а Chromium отказался от заголовка начиная с версии 107, потому что теперь применяет CT по умолчанию. Примечание на той же странице добавляет, что Expect-CT в основном устарел с июня 2021 года.

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

③ Что теперь может навредить

X-XSS-Protection: устаревший, нестандартный и способный создать XSS

На странице MDN об этом заголовке стоят сразу две пометки — Deprecated и Non-standard, а также предупреждение: хотя эта функция может защитить пользователей старых браузеров без поддержки CSP, в некоторых случаях X-XSS-Protection может создавать XSS-уязвимости на сайтах, которые иначе были бы безопасны.

Рекомендация однозначна: вместо XSS-фильтрации рекомендуется использовать Content-Security-Policy.

Это решающий довод против принципа «чем больше заголовков, тем лучше». Настройка, добавленная из лучших побуждений, при определённых условиях сама становится точкой атаки. Если вы его не отправляете, не добавляйте; если отправляете, запланируйте удаление. О самой уязвимости — в статье что такое XSS.

Как выглядит устаревший список

CSP, HSTS, X-Frame-Options и nosniff — плюс
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …

Список длиннее, и некоторые сканеры могут даже оценить его выше. Но в современных браузерах эти лишние строки либо ничего не делают, либо могут навредить.

Как выглядит практика сейчас

CSP в центре, остальные пять его дополняют.

Устаревшие заголовки не добавляются, а где есть — удаляются. Усилия, вложенные в качество CSP — а именно в то, сколько 'unsafe-inline' вы убрали, — дают гораздо больше реальной защиты, чем удлинение списка.

Исходное условие: заголовки не исправляют саму уязвимость

Дефекты приложения (XSS, отсутствие проверки прав, загрузка файлов)

никакое число заголовков их не устраняет

↓ когда такой дефект срабатывает

Чем управляют заголовки

куда можно отправлять данные · можно ли встроить страницу во фрейм · разрешён ли незашифрованный канал = ограничение распространения

Заголовки не меняют того, есть ли уязвимость. Они меняют, как далеко дойдёт ущерб, если она есть.

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

Проверка своего сайта

1

Измерьте, что на самом деле возвращается

Смотрите на ответы, а не на файлы настроек. Обратные прокси, CDN, фреймворки и само приложение добавляют или перезаписывают заголовки, поэтому настроенное и отправляемое не всегда совпадают. Наш сканер заголовков проверяет URL напрямую.

2

Ищите в ответе устаревшие заголовки

Если возвращаются X-XSS-Protection или Expect-CT, запланируйте их удаление. Особенно первый — как сказано выше, в документации отмечено, что он может создать уязвимость.

3

Добавьте четыре заголовка, которые ничего не сломают

X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin и Permissions-Policy, закрывающий неиспользуемые возможности. Надёжно и вряд ли повлияет на отображение.

4

Отложите HSTS, пока HTTPS не заработает полностью

Strict-Transport-Security запоминается браузером, поэтому если включить его, пока HTTPS работает нестабильно, восстановление будет болезненным. Сначала убедитесь, что все пути отдаются по HTTPS. Основы сертификатов — в статье что такое Let's Encrypt.

5

Вводите CSP постепенно и ужесточайте

Начните с мягкой политики и ужесточайте её с целью убрать 'unsafe-inline' — от того, насколько это удастся, во многом зависит, сколько защиты даёт CSP. Собирайте его в конструкторе CSP и заодно пройдитесь по остальным пунктам чек-листа базовой безопасности.

Взгляд этого сайта: в скопированной настройке безопасность зависит от возраста источника

Заголовки безопасности — типичная настройка, которую копируют, поэтому от возраста источника зависит, насколько безопасен результат. Оба заголовка из этой статьи когда-то были правильными. С X-XSS-Protection всё зашло дальше: рекомендация своего времени стала сегодняшним предупреждением.

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

Источники (первичные)

  • MDN Web Docs, «X-XSS-Protection» — developer.mozilla.org (пометки Deprecated и Non-standard, предупреждение о том, что заголовок может создавать XSS-уязвимости на безопасных сайтах, и рекомендация использовать CSP)
  • MDN Web Docs, «Expect-CT» — developer.mozilla.org (пометка Deprecated, отказ в Chromium 107 и его причина, примечание о том, что заголовок в основном устарел с июня 2021 года)

Оба источника проверены 5 сентября 2026 года.

Что прочитать дальше

FAQ

QНужно ли ставить X-XSS-Protection?
A

Нет. MDN помечает этот заголовок как Deprecated (устаревший) и Non-standard (нестандартный) и предупреждает: хотя он может защитить пользователей старых браузеров без поддержки CSP, в некоторых случаях X-XSS-Protection может создавать XSS-уязвимости на сайтах, которые иначе были бы безопасны. Рекомендация однозначна: использовать Content-Security-Policy вместо XSS-фильтрации. Если вы его не отправляете, не добавляйте; если отправляете, запланируйте удаление.

QНужен ли ещё Expect-CT?
A

Нет. MDN помечает его как Deprecated и поясняет, что его реализовали только Google Chrome и другие браузеры на Chromium, а Chromium отказался от заголовка начиная с версии 107, потому что теперь применяет Certificate Transparency по умолчанию. В примечании на той же странице сказано, что заголовок в основном устарел с июня 2021 года. Добавлять его во что-то новое незачем.

QТак какие же ставить?
A

Практичная отправная точка — шесть заголовков, по которым оценивает наш инструмент проверки: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy и Permissions-Policy. Устаревшие заголовки в этот набор намеренно не входят. По порядку: сначала добавьте надёжные и вряд ли что-то ломающие (nosniff, X-Frame-Options), а CSP вводите постепенно, потому что он затрагивает больше всего функций.

QЕсли поставить все заголовки, сайт будет защищён?
A

Нет. Заголовки не исправляют уязвимости в приложении — они ограничивают, насколько далеко распространится ущерб. CSP на сайте с XSS-уязвимостью не убирает XSS, а сужает то, что с ней можно сделать. Сначала исправьте дефект приложения, а заголовки добавьте как ещё один уровень защиты. И наоборот: идеальная оценка сканера заголовков не доказывает, что сайт безопасен.