Введение
Ребята, всем привет! Недавно в очередной раз взялся за усиление безопасности своего сайта и понял, что одна из самых важных, но часто недооценённых вещей — это настройка HTTP-заголовков безопасности. Многие слышали про них, некоторые даже знают названия, типа Content-Security-Policy или HSTS, но на деле кто-то просто пихает на сервер пару строчек и забывает, а у кого-то из-за кривой настройки ломается сайт. Короче, решил собрать всё в одном месте — что это такое, зачем нужно, какие подводные камни, и что реально помогает. Если у вас тоже стоит вопрос — заходите, обсудим!

Что такое заголовки безопасности и зачем они нужны
HTTP-заголовки безопасности — это такие штуки, которые сервер отправляет вместе с ответом браузеру и которые помогают браузеру понять, что именно можно и нельзя делать с загруженным сайтом. По сути, это дополнительный уровень защиты, который работает на стороне клиента и мешает злоумышленникам использовать всякие распространённые уязвимости — например, межсайтовый скриптинг (XSS), кликджекинг, MIME-type подделки и прочее. Они не «волшебная таблетка», не закрывают 100% дыр, но значительно повышают безопасность без особого ущерба для функционала.

Самые популярные заголовки:

- Content-Security-Policy (CSP) — самый мощный заголовок, позволяющий жёстко контролировать источники контента (скрипты, стили, изображения, шрифты и так далее). Очень помогает бороться с XSS.
- X-Frame-Options — блокирует внедрение сайта в iframe, чтобы защитить пользователей от clickjacking-атак.
- X-Content-Type-Options — останавливает браузер от попыток угадать MIME-тип, если он указан некорректно, предотвращая ряд проблем с обработкой контента.
- Strict-Transport-Security (HSTS) — заставляет браузер всегда использовать HTTPS, даже если пользователь ввёл HTTP, что важно для предотвращения MITM-атак.
- Referrer-Policy — контролирует, какую информацию о предыдущем сайте браузер отправляет в заголовке Referer, что повышает приватность.
- Feature-Policy (или Permissions-Policy) — позволяет управлять доступом к определённым функциям браузера, вроде геолокации или камеры, напрямую с сервера.

Где и как применяются заголовки
Чаще всего эти заголовки настраиваются напрямую в конфигурации веб-сервера, например, в nginx или Apache. Это самый простой и универсальный способ — плюс их подхватывают все запросы и ответы. Иногда их добавляют в кодах приложений, особенно если используется какие-то микросервисы или динамическая генерация. Ещё можно поднять свою прокси, который будет дописывать заголовки.

Ещё вариант — панели хостинга, которые дают удобный интерфейс для быстрой настройки (для начала сойдёт, но сильно кастомизировать там сложно). Главное — не забывать тестировать, чтобы настройка не сломала загрузку скриптов или стилей.

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

Глубже по основным заголовкам и примеры их настройки

Content-Security-Policy (CSP)
Этот заголовок — главный герой в борьбе с XSS и многими другими видами атак. Он описывает, откуда браузер может загружать скрипты, стили, изображения, шрифты, фреймы и так далее. Пример базовой политики:

default-src 'self';
img-src 'self' https://trusted.com;
script-src 'self' https://apis.google.com;
style-src 'self' 'unsafe-inline';

Здесь мы говорим: разрешаем всё с нашего домена ('self'), картинки только с нашего домена и https://trusted.com, скрипты с нашего домена и Google API, стили с себя и inline стили (для тех случаев, когда они действительно нужны).

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

X-Frame-Options
Очень простой заголовок, который запрещает размещать сайт в iframe — это блокирует атаки clickjacking. Например, строчка в конфиге nginx:

add_header X-Frame-Options "SAMEORIGIN";

означает, что только страница с того же домена может встраивать этот сайт в iframe. Можно также запрещать встраивание совсем (DENY) или разрешать только с определённого сайта (ALLOW-FROM), хотя ALLOW-FROM уже почти не поддерживается.

X-Content-Type-Options
Добавляется, чтобы браузер строго воспринимал указанный тип контента и не пытался его угадать. В nginx обычно так:

add_header X-Content-Type-Options nosniff;

Это помогает избежать проблем, когда браузер пытается интерпретировать контент не так, как сервер указал, и может защитить от некоторых эксплойтов на базе MIME.

Strict-Transport-Security (HSTS)
Очень важный заголовок, если ваш сайт работает по HTTPS. Он говорит браузеру: в течение указанного срока надо заходить только по HTTPS, игнорируя HTTP-запросы. Пример:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

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

Если забыть этот заголовок, то уязвимость «падения» на HTTP раунд-трип (man-in-the-middle) остаётся.

Реальный кейс: один из наших сайтов, где не был включён HSTS, столкнулся с ситуацией, что злоумышленник смог внедрить рекламу через MITM в открытом Wi-Fi — после включения HSTS этот вектор закрылся.

Referrer-Policy
Настраивает, какую информацию о странице, с которой пришёл пользователь, передавать дальше. Можно полностью убирать реферер или ограничить до домена:

add_header Referrer-Policy "strict-origin-when-cross-origin";

Штука скорее для улучшения приватности и защиты от утечек.

Permissions-Policy (ранее Feature-Policy)
Позволяет контролировать доступ к отдельным функциям браузера, например, камере, микрофону, геолокации:

add_header Permissions-Policy "geolocation=(), microphone=()";

Здесь мы запрещаем использование геолокации и микрофона на странице. Можно разрешать конкретным сайтам.

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

- Пытаться сразу поставить супержёсткие правила CSP без тестирования, из-за чего ломается весь сайт (например, скрипты аналитики, виджеты или реклама не работают).
- Забывать про inline-скрипты и стили, когда сайт их активно использует (если не прописать 'unsafe-inline', будут проблемы).
- Указывать неправильные домены или не учитывать протокол (http vs https).
- Не проверять поведение сайта после внедрения HSTS — могут появиться проблемы при переходе с http.
- Думать, что один заголовок решит все проблемы — лучше использовать их в связке.
- Не тестировать на разных браузерах, у них бывает разная поддержка заголовков.
- Добавлять заголовки на уровне приложения, при этом сервер всё равно переписывает или дублирует их, что вызывает конфликты.
- Не использовать отчёты CSP (report-uri), чтобы мониторить нарушения политики.

Чек-лист для прокачки безопасности через заголовки

- Запустить сайт с базовыми заголовками:
- X-Content-Type-Options: nosniff
- X-Frame-Options: SAMEORIGIN
- Referrer-Policy: strict-origin-when-cross-origin
- Включить HSTS, если сайт работает на HTTPS (после точного тестирования переходов)
- Добавить Content-Security-Policy с постепенным ужесточением (сначала с report-only)
- Использовать Permissions-Policy для отключения редко используемых или потенциально опасных функций браузера
- Активно мониторить ошибки CSP (через report-uri или аналогичные инструменты)
- Проверять работу сайта и функционала на разных браузерах
- Делать резервные копии конфигураций перед изменениями
- Использовать инструменты проверки безопасности, например, securityheaders.com или observatory.mozilla.org

FAQ — самые частые вопросы

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

Вопрос: Как не сломать рекламу или виджеты при жестком CSP?
Ответ: Добавляйте домены рекламных сетей и ресурсов явно в policy, иногда приходится разрешать inline-скрипты через nonce или hash.

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

Вопрос: Можно ли всё настроить через CMS или придется лезть в конфиги сервера?
Ответ: В большинстве случаев CMS позволяют добавить базовые заголовки, но для тонкой настройки лучше править конфиги сервера или использовать прокси.

Вопрос: А если мой сайт не HTTPS?
Ответ: HSTS тогда бессмысленен, а остальные заголовки всё равно помогают. Но стоит задуматься о переходе на HTTPS.

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