Введение

Если у вас есть сайт, то вы, скорее всего, слышали про такие штуки, как «заголовки безопасности». Это особые HTTP-заголовки, которые сервер отправляет браузеру вместе с ответом, чтобы браузер знал, как правильно себя вести с вашим сайтом. По сути, они создают дополнительные правила, которые ограничивают некоторые опасные действия, снижают риски взломов и защищают пользователей. Если настроить их правильно, это будет дополнительный рубеж обороны, который поможет избежать разных атак, например, межсайтового скриптинга (XSS) или кликджекинга. Сегодня я хочу поделиться практическим взглядом на это — что это вообще такое, зачем нужно, как их настраивать, на что обращать внимание, и какие популярные ошибки при этом встречаются.

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

Заголовки безопасности — это инструкции, которые сервер передает браузеру в виде HTTP-заголовков. Они не видны пользователю напрямую, но влияют на поведение браузера, например, запретить загрузку скриптов с подозрительных источников, запретить отображение сайта в iframe на других доменах (чтобы избежать встраивания в чужие страницы), установить ограничения на куки, запретить загрузку ресурсов по протоколу HTTP, если сайт работает по HTTPS, и многое другое. Это дополнение к стандартным методам защиты, таким как брандмауэры, фильтры или сам код приложения. Их задача — фильтровать и ограничивать возможности браузера именно в контексте безопасности.

Зачем это нужно

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

Например, Content-Security-Policy (CSP) позволяет указать, откуда можно загружать скрипты, стили, изображения и другие ресурсы. Если CSP настроена правильно, то даже если в коде есть уязвимость XSS, вредоносный скрипт не сможет работать, так как браузер просто не загрузит его или не исполнит. Другие заголовки, как X-Frame-Options, защищают от iframe-кликджекинга, где ваш сайт подсовывают в iframe на другой странице, чтобы обмануть пользователя.

Где применять заголовки

Основная аудитория для настройки этих заголовков — публичные сайты и веб-приложения, особенно те, на которых есть пользовательская авторизация, формы ввода (регистрация, комментарии, поиск), сложные клиентские скрипты, AJAX-запросы, а также панели администрирования. Чем чувствительнее данные и функционал на сайте, тем важнее запустить эти ограничения.

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

Как настроить — основные заголовки безопасности и их примеры

1. Content-Security-Policy (CSP)

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

Пример простейшей политики:

Content-Security-Policy: default-src 'self';

Это значит, что все ресурсы должны загружаться только с того же домена, где размещён сайт.

Если на сайте есть внешние скрипты (например, Google Analytics), их нужно добавить:

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google-analytics.com;

Ещё пример для разрешения стилей с CDN:

Content-Security-Policy: default-src 'self'; style-src 'self' https://fonts.googleapis.com;

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

2. X-Frame-Options

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

Значения:

- DENY — запрещает встраивание в iframe совсем.

- SAMEORIGIN — разрешает только если iframe с того же домена.

- ALLOW-FROM uri — разрешает только с указанного домена (редко поддерживается).

Пример:

X-Frame-Options: SAMEORIGIN

3. X-Content-Type-Options

Защищает от так называемой mime-type sniffing ошибки, когда браузер пытается угадать тип файла, и может запускать не тот контент, например, скрипт вместо изображения.

Используется обычно так:

X-Content-Type-Options: nosniff

4. Referrer-Policy

Этот заголовок контролирует, какую информацию о предыдущей странице браузер отправляет вместе с запросом.

Например:

Referrer-Policy: no-referrer

полностью отключает передачу реферера.

Или более лояльный вариант:

Referrer-Policy: strict-origin-when-cross-origin

5. Strict-Transport-Security (HSTS)

Если вы делаете сайт на HTTPS (а делать стоит!), с помощью этого заголовка рассказываете браузеру, чтобы он использовал только HTTPS и не делал переходы по HTTP.

Выглядит так:

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

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

includeSubDomains — применяется ко всем поддоменам.

preload — заявка для HSTS Preload List (чтобы браузеры заранее знали об обязательном HTTPS).

Как включать

Чтобы установить эти заголовки, нужно править конфигурацию веб-сервера (например, nginx, Apache), или настроить их в коде приложения (PHP, Node.js, Python и т.д.).

В nginx можно добавить директивы в блок server:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.google-analytics.com;";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Аналогично для Apache через .htaccess или httpd.conf с директивой Header set.

Также многие CMS и фреймворки имеют плагины или встроенные средства для выставления этих заголовков.

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

- Заголовок выставлен некорректно или с ошибками в синтаксисе, из-за чего браузер их игнорирует.

- CSP слишком жесткая, из-за чего ломается функционал сайта (например, не загружаются нужные скрипты).

- Заголовки конфликтуют между собой или с политиками сайта.

- Путают HTTP заголовки и метатеги (всё нужно ставить именно в заголовках сервера).

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

- Забывают контролировать HSTS — если включили с preload, потом сложно отключить.

- Добавляют cope-код в заголовок, не проверяя актуальность API.

- Забивают на регулярный аудит и обновление этих заголовков.

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

1. Определитесь, какие внешние ресурсы и сервисы вы реально используете.

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

3. Напишите и протестируйте Content-Security-Policy, начиная с менее строгой и постепенно усиливая.

4. Добавьте X-Frame-Options со значением SAMEORIGIN или DENY, если встраивание не нужно.

5. Включите X-Content-Type-Options: nosniff.

6. Настройте Referrer-Policy, ориентируясь на конфиденциальность пользователей.

7. Включите Strict-Transport-Security, если используете HTTPS.

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

9. Постоянно мониторьте логи и обновляйте настройки по мере появления новых требований.

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

- Можно ли использовать заголовки безопасности на обычном HTTP?

Есть смысл только для HSTS, но он будет работать только на HTTPS. Для остальных заголовков HTTPS — обязательное условие.

- Есть ли готовые шаблоны CSP?

Да, в интернете полно генераторов и примеров. Но универсального шаблона нет, всё зависит от конкретного сайта и используемых ресурсов.

- Что делать, если после включения CSP что-то перестало работать?

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

- Насколько важно обновлять заголовки?

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

- Можно ли настроить заголовки в CMS?

Часто да, через плагины или встроенные настройки. Например, в WordPress есть плагины для CSP и HSTS.

- Можно ли тестировать CSP без блокирования?

Да, можно использовать директиву Content-Security-Policy-Report-Only, чтобы получать отчёты без применения политики и смотреть, что ломается.

Заключение

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