HSTS для WordPress: принудительное использование HTTPS

Что такое HSTS и от чего он защищает

HSTS — это специальный HTTP-заголовок Strict-Transport-Security. После получения этого заголовка браузер в течение заданного периода автоматически заменяет обращения к домену через http:// на HTTPS. Пользователю не нужно каждый раз вручную вводить защищённый адрес.

Механизм снижает риск downgrade-атак, при которых пользователя пытаются перевести с HTTPS на HTTP. Он также помогает избежать случайного открытия незащищённой версии сайта по старой ссылке.

HSTS не устанавливает SSL-сертификат, не шифрует сервер и не заменяет перенаправление с HTTP на HTTPS. Сервер по-прежнему должен корректно обрабатывать HTTP-запросы и перенаправлять их на защищённый адрес. HSTS — это дополнительное правило для браузера, а не замена базовой настройке HTTPS.

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

Какие параметры есть у заголовка Strict-Transport-Security

Базовый заголовок содержит параметр max-age — период в секундах, в течение которого браузер применяет политику. Для рабочего сайта обычно используют не менее 15552000 секунд, то есть примерно 180 дней. Распространённый долгосрочный вариант — 31536000 секунд, или один год.

Параметр includeSubDomains распространяет правило на все поддомены. Включать его можно только в том случае, если у каждого поддомена работает HTTPS и установлен корректный сертификат. Это относится не только к сайту на WordPress, но и к почте, тестовым средам, панелям, API, CDN и другим сервисам на поддоменах.

Параметр preload предназначен для добавления домена в предварительно загружаемые списки браузеров. Это не просто «усиленная версия» HSTS: для него нужны дополнительные условия, включая длительный max-age, includeSubDomains и полную доступность всех поддоменов по HTTPS. Исправление ошибочного добавления в preload может занять много времени.

• Осторожный старт: Strict-Transport-Security: max-age=300
• После проверки: Strict-Transport-Security: max-age=15552000
• Для стабильного домена: Strict-Transport-Security: max-age=31536000; includeSubDomains
• Добавляйте preload только после отдельного аудита домена и всех его поддоменов.

Подготовка WordPress к принудительному HTTPS

Перед добавлением HSTS убедитесь, что WordPress работает с правильными адресами. Адрес WordPress и адрес сайта должны использовать https://, а не http://. Если HTTP-адрес остался в конфигурации, базе данных или настройках прокси, могут возникнуть циклические редиректы, неправильные canonical-адреса или смешанный контент.

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

Если сайт работает через CDN или reverse proxy, необходимо правильно передавать информацию о протоколе в WordPress. Иначе сервер может считать запрос HTTP даже тогда, когда посетитель уже подключён по HTTPS, что приводит к бесконечным перенаправлениям.

• Проверьте адрес WordPress и адрес сайта: оба должны начинаться с https://.
• Убедитесь, что редирект HTTP → HTTPS не создаёт цепочки и циклы.
• Проверьте сертификат основного домена и всех необходимых поддоменов.
• После смены протокола очистите кэш WordPress, CDN и браузера.
• Не включайте HSTS на тестовом домене, если его инфраструктура часто меняется.

Как добавить HSTS на веб-сервере

Надёжнее всего добавлять HSTS на уровне веб-сервера или reverse proxy, чтобы заголовок передавался со всеми ответами, а не только со страницами, созданными WordPress. Важно, чтобы он передавался именно через HTTPS. Добавление заголовка к HTTP-ответам не обеспечивает полезной защиты.

Ниже приведены типовые примеры. Перед изменением конфигурации создайте резервную копию и проверьте синтаксис конфигурации. Точное расположение директивы зависит от структуры сервера, панели управления и схемы прокси.

Для Apache:
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=15552000"
</IfModule>

Для Nginx:
add_header Strict-Transport-Security "max-age=15552000" always;

Вариант с поддоменами

Если все поддомены проверены и доступны по HTTPS, можно использовать includeSubDomains:

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

Добавление через WordPress

Некоторые инструменты безопасности или собственный код могут добавлять заголовок через WordPress. Такой способ допустим, но его нужно проверить для ошибочных ответов, редиректов, статических файлов и ответов, которые формирует сервер или CDN. Если заголовок добавляется в нескольких местах, убедитесь, что разные значения не конфликтуют.

Проверка Elementor и смешанного контента

После перехода на HTTPS часть страницы может оставаться доступной, но отдельные ресурсы будут загружаться через http://. Это называется mixed content, или смешанный контент. Браузер может заблокировать такие скрипты, шрифты, изображения или стили, из-за чего страница Elementor будет отображаться некорректно.

Проверьте HTML страниц, консоль браузера и вкладку сетевых запросов. Особое внимание уделите фоновой графике, видео, шрифтам, iframe, внешним библиотекам и URL в CSS. После исправления адресов очистите кэш и при необходимости перестройте сгенерированные CSS-файлы Elementor с помощью доступных инструментов конструктора.

Не следует механически заменять все вхождения http:// в базе данных без резервной копии. Данные WordPress могут быть сериализованными, поэтому некорректная замена способна повредить настройки виджетов или плагинов.

• Проверьте консоль браузера на сообщения о Mixed Content.
• Замените HTTP-адреса изображений, шрифтов, скриптов и стилей на HTTPS.
• Проверьте внешние iframe и ресурсы сторонних сервисов.
• После изменений очистите кэш браузера, WordPress, CDN и CSS конструктора.
• Просмотрите страницы в приватном режиме, чтобы не полагаться на старый кэш.

Безопасное поэтапное включение HSTS

HSTS лучше внедрять постепенно. Сначала установите короткий max-age, чтобы проверить работу сайта в реальных браузерах. Если проблем нет, увеличьте период до 15552000 или 31536000 секунд.

После каждого изменения проверяйте не только главную страницу, но и авторизацию, панель администратора, формы, загрузку файлов, API, платёжные интеграции и страницы, которые обслуживаются отдельным сервером. Также протестируйте мобильные устройства и разные браузеры.

Добавляйте includeSubDomains только после инвентаризации DNS и серверов. Список должен включать даже редко используемые поддомены: staging, old, dev, mail, status, api и служебные адреса. Если хотя бы один из них не поддерживает HTTPS, унаследованная политика может заблокировать доступ.

• Этап 1: проверить сертификаты, редиректы и смешанный контент.
• Этап 2: включить короткий max-age без includeSubDomains.
• Этап 3: проверить логи, ошибки браузера и работу панели администратора.
• Этап 4: увеличить max-age после стабилизации.
• Этап 5: добавить includeSubDomains и только затем рассматривать preload.

Типичные ошибки и диагностика

Самая распространённая ошибка — сразу добавить HSTS с includeSubDomains и preload, не проверив старые поддомены. Другая проблема — настроить заголовок в WordPress, но забыть о CDN или балансировщике, который перезаписывает или удаляет его.

Фактический заголовок можно увидеть в инструментах разработчика браузера или с помощью команды curl. Проверяйте HTTPS-ответ, а не только результат перенаправления с HTTP.

• Неправильное значение max-age или синтаксическая ошибка в заголовке.
• HSTS добавляется только для HTML, но отсутствует в других HTTPS-ответах.
• HTTP-редирект ведёт на другой домен, неправильный порт или промежуточный адрес.
• Сертификат не охватывает поддомен, унаследовавший политику.
• После тестирования кажется, что проблема исчезла, но браузер всё ещё использует старый кэш.
• preload включён до завершения аудита всех поддоменов.

curl -I https://example.com

В ответе должна быть строка примерно такого вида:
Strict-Transport-Security: max-age=15552000