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