Проверить сайт

Как настроить HSTS и security-заголовки на сайте

Security headers — это строки в HTTP-ответе сервера, которые говорят браузеру, как обращаться с страницей. Вместе со строгим заголовком Strict-Transport-Security (HSTS) они закрывают типовые уязвимости: переход обратно на HTTP, встраивание формы во фрейм и автозагрузку неожиданного ресурса. Разберём, какие заголовки ставить, как не сломать HTTPS и при чём тут SEO.

Что такое security headers и зачем они для безопасности и SEO

Если коротко, это подсказки браузеру. Сервер отправляет их вместе с кодом ответа (например, 200 или 404), а клиент уже решает, можно ли показывать контент так, как он запросили. Отдельные заголовки защищают от конкретных векторов: один не даёт встроить страницу в iframe, другой запрещает браузеру «догадываться» о типе файла, третий запоминает, что сайт должен открываться только по HTTPS.

Откуда берётся связь с SEO? Прямой кнопки роста позиций эти заголовки не нажимают — об этом ниже. Но они работают на два фактора, которые поисковики действительно учитывают:

  • Стабильность и доступность канонического адреса. HSTS не даёт браузеру вернуться к HTTP-версии после успешного визита по HTTPS. Если страница постоянно открывается по защищённому адресу без конфликтующих зеркал, краулеру проще её проиндексировать.
  • Доверие к домену. Защищённый сайт с корректным SSL-сертификатом, без предупреждений браузера и без встраивания со стороны воспринимается как надёжный. А это косвенно влияет на поведенческие факторы и на то, как часто пользователь возвращается.

Отдельно отмечу: security headers не заменяют обновления CMS, правильный сертификат или контроль доступа. Это дополнительный слой защиты от типовых ошибок, а не панацея. Настроить их стоит хотя бы потому, что это быстро, бесплатно и почти не влияет на скорость загрузки.

Строгие заголовки: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy

Рассмотрим четыре заголовка, которые покрывают большинство реальных рисков. Остальные — вроде Content-Security-Policy — добавляю отдельно, потому что там есть нюансы, которые легко сломать.

Strict-Transport-Security (HSTS)

Этот заголовок заставляет браузер запомнить, что домен работает только по HTTPS. Задал max-age, и даже если где-то в коде осталась ссылка на http://, браузер сам переправит запрос на https.

Главное правило: включать HSTS можно только после того, как HTTPS стабильно работает на всех страницах. Иначе вы «заперёте» пользователей на сломанной версии — откатиться обратно на HTTP станет невозможно пока не истечёт max-age. На практике я рекомендую такой порядок:

  1. Сначала ставите небольшой max-age, например 300 или 86400 секунд, и смотрите, нет ли падений.
  2. Увеличиваете до 31536000 (год) только когда уверены в стабильности.
  3. includeSubDomains добавляете лишь тогда, когда каждый поддомен — и почта, и staging, и старые лендинги — уже сидит на HTTPS.

X-Frame-Options

Запрещает встраивать вашу страницу в iframe на чужих сайтах. Защищает от clickjacking — когда поверх видимой кнопки прячется невидимая, и пользователь кликает не туда. Варианты значения: SAMEORIGIN (разрешить только своим страницам) или DENY (запретить полностью).

Современная замена — директива frame-ancestors внутри CSP, но X-Frame-Options остаётся полезной защитой для простых сайтов и старых браузеров. Прежде чем ставить DENY, проверьте, не встраивает ли вас законно партнёр или платёжный виджет.

X-Content-Type-Options: nosniff

Говорит браузеру не «догадываться» о типе файла, если сервер указал его неверно. Без этого заголовка браузер может открыть картинку как скрипт и выполнить её. Значение всегда одно — nosniff. Ставится почти без риска, поэтому его можно включить в первую очередь.

Referrer-Policy

Контролирует, какая информация о странице отправляется в Referer при переходе на другой сайт. По умолчанию могут утекать пути с параметрами, токенами и прочими чувствительными данными. Рекомендую strict-origin-when-cross-origin: на своих доменах реферер передаётся полностью, на чужих — только схема и хост, без путей.

Заголовок Что делает Риски отключения
Strict-Transport-Security Заставляет использовать HTTPS Возврат на HTTP, MITM-атаки
X-Frame-Options Запрещает встраивание в iframe Clickjacking
X-Content-Type-Options: nosniff Отключает MIME-sniffing Выполнение ресурсов под видом другого типа
Referrer-Policy Ограничивает передачу Referer Утечка путей и параметров запроса

Content-Security-Policy: не копировать, а настраивать

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

Не копируйте CSP с чужого сайта: набор источников у всех разный, и готовая политика либо ничего не защитит, либо заблокирует половину контента. Правильно так:

  1. Сначала включаете режим Content-Security-Policy-Report-Only. Он показывает в лог, что было бы заблокировано, но не ломает страницу посетителю.
  2. Смотрите отчёты: какие скрипты, аналитика, шрифты и платёжные виджеты светятся как подозрительные.
  3. Пишете политику, разрешающую только нужные источники (default-src 'self' и конкретные домены), и переключаете в рабочий режим.

Режим Report-Only — это способ протестировать CSP без риска для трафика. Переходить на строгий режим стоит, когда вы уверены в архитектуре сайта.

Как настроить security headers: nginx и Apache

Ниже — базовый набор для уже работающего HTTPS. Оба конфига помечены always, чтобы заголовок ставился даже на ошибках 404 и 500.

nginx

server {
    listen 443 ssl http2;
    server_name example.com;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

Для режима Report-Only CSP добавляете отдельную строку:

add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report" always;

Apache

<IfModule mod_headers.c>
    Header set Strict-Transport-Security "max-age=63072000; includeSubDomains" always
    Header set X-Content-Type-Options "nosniff" always
    Header set X-Frame-Options "SAMEORIGIN" always
    Header set Referrer-Policy "strict-origin-when-cross-origin" always
</IfModule>

Важные нюансы: в nginx заголовок нужно задавать именно в блоке server/location с listen 443, иначе на HTTP-версии HSTS не имеет смысла. В Apache модуль mod_headers должен быть подключён — без него директивы проигнорируются без ошибок. Если сайт работает за Cloudflare или другим прокси, часть заголовков можно выставлять в его панели, но проверьте, что они действительно доходят до браузера.

Отдельно про скорость: правильно настроенные заголовки почти не влияют на неё, а вот грамотное кэширование и gzip дают реальный прирост производительности. Эти две вещи стоит настроить вместе — безопасность и скорость не противоречат друг другу.

Влияние на доверие поисковиков и безопасность

Прямого фактора ранжирования security headers не имеют: это не «кнопка роста», как сам HSTS, а элемент технической гигиены. Но эффект на доверие есть, и он заметен в двух направлениях.

Для безопасности. Набор из HSTS, X-Content-Type-Options и X-Frame-Options закрывает сразу несколько типовых уязвимостей без кода на стороне приложения. Это тот минимум, который стоит иметь даже на простом лендинге. Более продвинутые механизмы — CSP и WAF — это разные уровни: CSP ограничивает загрузку ресурсов в браузере посетителя, а WAF фильтрует запросы к самому серверу. Один механизм другой не отменяет.

Для SEO косвенно. Защищённый сайт без предупреждений «Не безопасно», со стабильным HTTPS и без чужих фреймов вызывает больше доверия у человека. А поведенческие сигналы — время на сайте, отказы, возвраты — поисковики всё так же учитывают. Плюс корректный robots.txt вместе с HSTS помогает краулеру не путаться между HTTP и HTTPS зеркалами, что снижает риск дублей.

Итог: security headers — это про надёжность и репутацию домена, а уже через них — про стабильное ранжирование без технических сбоев.

Как проверить security headers: инструменты и curl -I

Посмотреть фактические заголовки можно по-разному. Самый быстрый способ из терминала — команда с флагом -I, она делает HEAD-запрос и выводит только заголовки:

curl -I https://example.com

В ответе ищите строки Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Обратите внимание: HSTS виден только на HTTPS-версии, на HTTP его не будет по определению. Если заголовков нет — проверьте, применяются ли они в правильном блоке конфига и доходит ли запрос через ваш прокси.

Для удобства есть онлайн-инструменты и сервисные проверки: можно проверить HTTP-заголовки по отдельности или сделать полную проверку HSTS. Они покажут не только наличие, но и корректность значений — например, тот самый max-age и флаг includeSubDomains.

Как проверить security headers в seoquest.ru

Чтобы не гадать вручную, возьмите общую техническую картину за один раз. Бесплатная проверка на seoquest.ru/check/free даёт Health Score и SEO-аудит, где заголовки безопасности идут среди прочих технических параметров. Вы сразу видите, какие headers отсутствуют или настроены с ошибками, и получаете конкретные рекомендации по исправлению — без необходимости разбирать вывод curl по памяти.

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

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

Влияет ли HSTS на ранжирование напрямую?

Нет. Его задача — не давать браузеру вернуться к HTTP после успешного визита по HTTPS. Для поиска важнее, что канонические страницы стабильно доступны по защищённому адресу без конфликтующих зеркал.

Можно ли сразу включить includeSubDomains?

Только если вы проверили все поддомены — старые лендинги, почтовые интерфейсы, staging. Один сервис без HTTPS станет недоступен тем пользователям, чьи браузеры уже запомнили политику родительского домена.

Зачем CSP, если есть антивирус и WAF?

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

Нужен ли X-Frame-Options вместе с CSP?

Современный вариант — директива frame-ancestors в CSP, но X-Frame-Options остаётся полезной защитой для простых случаев. Проверьте, не требуется ли законное встраивание страницы партнёром или платёжным сценарием.

Robots.txt защищает от атак?

Нет. Robots.txt — добровольная подсказка поисковым краулерам, а не фаервол и не контроль доступа. Закрытые данные должны требовать авторизацию, а серверные правила и заголовки работают независимо от robots.txt.