Введение
Наверное, многие из вас слышали о заголовках безопасности, или security headers, но не все до конца осознают, зачем они нужны и как их правильно использовать на практике. Я сам начал разбираться с ними, когда помогал с настройками безопасности на нескольких сайтах — и CMS, и самописных проектах. В этой теме хочу поделиться своим опытом, объяснить, что это вообще такое, зачем устанавливать эти заголовки и на что стоит обращать внимание, чтобы не запороть работу сайта.

Что такое заголовки безопасности и зачем они нужны
Вкратце, заголовки безопасности — это специальные HTTP-заголовки, которые сервер отдаёт вместе с ответом на запрос страницы. Они задают браузеру правила, как вести себя с получаемым контентом. Можно запретить загрузку скриптов с неизвестных источников, запретить встраивание страницы в iframe на чужих сайтах, запретить браузеру пытаться угадать тип контента, ограничить передачу информации о том, откуда пришёл пользователь, и ещё много чего.

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

Где и когда использовать заголовки безопасности
Чаще всего эти заголовки нужны на сайтах с чувствительной информацией: интернет-магазинах с платежами, личных кабинетах, административных панелях, ресурсах с пользовательскими данными и прочих местах, где важна безопасность доступа. Но и на обычных лендингах или блогах, особенно если там используются внешние скрипты, стоит добавить хотя бы базовый набор. Даже на простом сайте, который отдаёт статику, можно попасть на проблемы, если отсутствуют минимальные меры защиты.

Если вообще брать, чем бы я рекомендовал начать — это простая установка X-Frame-Options и Content-Security-Policy, а на HTTPS-сайтах обязательно включить HSTS, чтобы избежать лишних рисков.

Практические примеры популярных заголовков безопасности

Content-Security-Policy (CSP)
Этот заголовок даёт самый гибкий и мощный контроль. С его помощью можно прописать, с каких доменов можно загружать скрипты, стили, изображения, шрифты и прочие ресурсы. Например, можно разрешить выполнение JS только с собственного домена и заблокировать всё остальное. Это супер полезно для борьбы с XSS: даже если злоумышленник внедрил вредоносный скрипт, браузер его просто не выполнит, если он не соответствует политике.

Пример ребята:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:;

Здесь мы разрешили загружать все ресурсы только с собственного домена, скрипты ещё и с нашего CDN, стили — с того же домена плюс разрешили inline-стили (это стоит с осторожностью), и изображения — с собственного домена и inline data URI.

Важно: CSP легко перегнуть палку. Если запретить inline-скрипты без дополнительной настройки, у вас перестанут работать нужные скрипты, например, Google Analytics, виджеты и т.п. Поэтому лучше запускайте сначала в режиме report-only, чтобы собрать статистику и понять, что реально ломается.

X-Frame-Options
Он запрещает встраивание страниц вашего сайта в iframe на других ресурсах. Это помогает бороться с clickjacking — неприятной атакой, когда злоумышленник скрывает интерфейс вашего сайта в iframe и заставляет пользователя нажимать на кнопки, думая, что Interact с другим ресурсом.

Самые популярные значения:
- DENY — запретить встраивание вообще в iframe
- SAMEORIGIN — разрешить встраивание только с ваших доменов
- ALLOW-FROM https://example.com — разрешить встраивание только с конкретного сайта (не поддерживается всеми браузерами)

Большинство сайтов ставит DENY или SAMEORIGIN — зависит от сценария, например, если у вас есть дочерние сайты, можно SAMEORIGIN.

X-Content-Type-Options
Заголовок говорит браузеру не пытаться угадать MIME-тип файлов, а использовать тот, который сервер отдаёт в Content-Type. Это важно, чтобы избежать ситуации, когда браузер воспринимает текстовый файл как HTML или JS и выполняет его, что открывает двери вредоносному коду. Обычно ставят значение nosniff.

Referrer-Policy
Контролирует, насколько браузер передаёт информацию про страницу, с которой пользователь пришёл на ваш сайт (HTTP_REFERER). Может снижать или повышать уровень приватности, в зависимости от политики.

Примеры значений:
- no-referrer — вообще не передавать реферер
- strict-origin-when-cross-origin — передавать только домен и только при безопасном соединении
- origin — передавать только домен

Зависит от того, насколько вы хотите не разглашать данные пользователей.

Strict-Transport-Security (HSTS)
Это мощный заголовок, который инструктирует браузер обращаться к сайту только по HTTPS, даже если пользователь введёт http:// в адресной строке. Это защищает от MITM-атак типа SSL stripping, когда злоумышленник пытается понизить уровень безопасности соединения.

Пример:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age — время действия политики в секундах (здесь год). includeSubDomains — распространяется на все поддомены. preload — флаг для попадания в список браузеров с предзагруженной политикой HSTS.

Типичные ошибки при настройке

Слишком строгий Content-Security-Policy
Самое частое — сайты перестают работать из-за чрезмерно жёстких правил CSP. Например, можно забыть разрешить js с нужных доменов или полностью запретить inline-скрипты, что ломает работу аналитики, виджетов и даже базовых функций. Чтобы избежать этого, всегда сначала пробуйте report-only режим, наблюдайте, кто и что пытается загрузить, и постепенно ужесточайте политику.

Пренебрежение HSTS
Если сайт работает по HTTPS, но не использует HSTS, это открывает путь для атак понижения уровня безопасности (SSL stripping). Особенно это опасно для сайтов с входом пользователей или платежами. Иногда забывают включить HSTS из-за опасений, что могут потерять доступ, если что-то сломается с сертификатом, но это стоит решать отдельно и не оставлять вообще без него.

Отсутствие X-Frame-Options
Без этого заголовка злоумышленник может встроить ваш сайт куда угодно в iframe и пытаться красть клики пользователей. Это не всегда критично, но часто именно этим пользуются при атаках социальной инженерии.

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

Чек-лист по заголовкам безопасности

- Включить Content-Security-Policy, начиная с report-only
- Добавить X-Frame-Options: DENY или SAMEORIGIN
- Установить X-Content-Type-Options: nosniff
- Прописать Referrer-Policy, подходящий для конфиденциальности (например, strict-origin-when-cross-origin)
- На HTTPS-сайте включить Strict-Transport-Security с адекватным max-age и includeSubDomains
- Проверить работу сайта на тестовом окружении после включения каждого заголовка
- Использовать инструменты для проверки и отчётов (о них расскажу ниже)

Полезные инструменты для проверки и настройки

- Security Headers (securityheaders.com) — бесплатный онлайн-тест, который проверит заголовки вашего сайта и даст советы
- Report-uri.com — сервис, куда CSP в режиме report-only присылает отчёты о попытках нарушения πολιтик, помогает отточить правила
- Mozilla Observatory — комплексный тест безопасности сайта с анализом множества параметров, включая заголовки
- Браузерные DevTools — вкладка Network показывает, какие заголовки приходят с сервера, удобно для быстрой проверки
- Конфигурация веб-сервера (Apache, Nginx) или CDN (Cloudflare, Yandex.Cloud) — можно настроить заголовки там

FAQ (часто задаваемые вопросы)

В: Можно ли ставить CSP сразу в жёстком режиме?
О: Рекомендуется сначала выставить report-only. Это даст понять, какие ресурсы блокируются и не работают без разрешения. После исправления ошибок уже переключить в enforcing mode.

В: Что важнее — CSP или HSTS?
О: Оба заголовка решают разные задачи. HSTS гарантирует безопасность протокола HTTPS и предотвращает атаки на уровне транспорта, а CSP борется с выполнением неподконтрольного кода в браузере. Желательно использовать их в комплексе.

В: Реферерpolicy сильно влияет на SEO?
О: Обычно нет, но стоит избегать политики, которая полностью блокирует рефереры, если вы рассчитываете на аналитику и отслеживание переходов. Лучше подобрать баланс безопасности и функционала.

В: Можно ли настроить заголовки безопасности прямо в CMS?
О: Многие современные CMS дают такую возможность через плагины или в настройках. Но иногда удобнее и правильнее делать это на уровне веб-сервера или CDN, чтобы не перезаписывать заголовки случайно.

В: Что делать, если заголовок ломает сайт?
О: Отменить или переключить на report-only и посмотреть, какие ресурсы блокируются. Возможно, нужно добавить доверенные источники в CSP или изменить политику X-Frame-Options.

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