HTTP-заголовки безпеки для WordPress: налаштування, перевірка та сумісність з Elementor

Що роблять основні заголовки безпеки

HTTP-заголовки безпеки передають браузеру правила обробки сторінки та її ресурсів. Вони не виправляють уразливості у WordPress і не замінюють оновлення, резервні копії чи контроль доступу, але зменшують кількість сценаріїв, які може використати зловмисник.

Для більшості WordPress-сайтів доцільно почати з чотирьох базових заголовків: X-Content-Type-Options, X-Frame-Options, Referrer-Policy та Permissions-Policy.

• X-Content-Type-Options: nosniff забороняє браузеру вгадувати MIME-тип файлу. Це зменшує ризик виконання ресурсу не в тому контексті, для якого його завантажили.
• X-Frame-Options: SAMEORIGIN дозволяє відкривати сторінки у frame лише в межах того самого джерела. Заголовок захищає від багатьох сценаріїв clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin обмежує передавання повного URL під час переходу на інший сайт, але зберігає більше інформації для переходів у межах того самого джерела.
• Permissions-Policy обмежує доступ сторінки до функцій браузера, наприклад камери, мікрофона та геолокації.

Налаштування заголовків в Apache

Для Apache заголовки зазвичай додають у конфігурацію VirtualHost або у файл .htaccess, якщо хостинг дозволяє використовувати mod_headers. Варіант із параметром always важливий: заголовки додаються не лише до успішних відповідей, а й до частини відповідей із помилками та перенаправленнями.

Розміщуйте правила в контексті, де вони не дублюються іншими конфігураціями або плагінами. Після зміни перевірте синтаксис конфігурації та перезапустіть або перезавантажте Apache згідно з правилами вашого хостингу.

• Перед редагуванням .htaccess створіть його резервну копію.
• Якщо сервер повертає помилку 500 після зміни, негайно приберіть останній блок і перевірте журнал помилок.
• Не додавайте один і той самий заголовок одночасно в Apache, Nginx, CDN та плагіні без перевірки: дублікати можуть спричинити непередбачувану поведінку.

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Налаштування заголовків у Nginx

У Nginx для цього використовують директиву add_header. Параметр always дає змогу додавати заголовок до ширшого набору відповідей, а не лише до стандартних успішних відповідей. Точне місце розміщення залежить від конфігурації сервера: це може бути блок server або відповідний блок location.

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

• Перевірте, чи не перезаписує заголовки конфігурація CDN або reverse proxy.
• Якщо Nginx працює перед Apache, з’ясуйте, на якому рівні фактично формується відповідь.
• Не копіюйте директиви Apache у конфігурацію Nginx: синтаксис у них різний.

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;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Що потрібно врахувати під час роботи з Elementor

Elementor та його додаткові віджети можуть використовувати JavaScript, AJAX-запити, iframe, веб-шрифти, зовнішні зображення, відеосервіси та інші домени. Базові заголовки зазвичай не створюють проблем, однак окремі налаштування можуть змінити поведінку редактора або опублікованої сторінки.

X-Frame-Options: SAMEORIGIN забороняє вбудовування сторінки на іншому домені. Якщо сайт має відкриватися всередині зовнішньої CRM, LMS, мобільної оболонки або іншого сервісу, цей заголовок потрібно перевірити окремо. Не послаблюйте його без чіткого розуміння, кому саме дозволено вбудовування.

Permissions-Policy не забороняє роботу звичайних контактних форм. Проте вона може вплинути на функції, яким справді потрібні камера, мікрофон або геолокація. Для відеоконференцій, завантаження фото з камери чи геосервісів правила потрібно налаштовувати адресно, а не залишати глобальну заборону.

• Перевірте відкриття редактора Elementor і збереження змін.
• Протестуйте форми, попапи, меню, слайдери та AJAX-фільтри.
• Перевірте сторінки з відео, картами, iframe та сторонніми віджетами.
• Переконайтеся, що ресурси теми й плагінів завантажуються без помилок у консолі браузера.

Чому з Content-Security-Policy не варто починати без тестування

Content-Security-Policy, або CSP, може суттєво обмежити виконання скриптів, завантаження стилів, шрифтів, зображень, iframe та підключення до сторонніх API. Це один із найпотужніших заголовків захисту від XSS, але водночас один із найскладніших у підтримці.

Надто сувора CSP-політика може зламати редактор Elementor, inline-скрипти, аналітику, CAPTCHA, платіжні модулі, форми та сторонні віджети. У WordPress немає універсального значення, яке безпечно підійде кожному сайту.

Якщо CSP потрібна, починайте з режиму звітування Content-Security-Policy-Report-Only. Він показує порушення в консолі або системі збору звітів, але не блокує ресурси. Після аналізу залежностей політику можна впроваджувати поступово, бажано на тестовій копії сайту.

• Не додавайте наосліп значення unsafe-inline або unsafe-eval лише для того, щоб прибрати помилки: це послаблює захист.
• Складіть список доменів, які реально використовують скрипти, шрифти, зображення, API та iframe.
• Після кожної зміни перевіряйте не тільки головну сторінку, а й редактор, форми, кошик, авторизацію та сторінки подяки.

Як перевірити, чи заголовки працюють

Перевіряти потрібно фактичну HTTP-відповідь, а не лише текст конфігурації. Відкрийте сайт у браузері, скористайтеся інструментами розробника та перегляньте вкладку Network для основного HTML-документа. У розділі Response Headers мають відображатися потрібні значення.

Для додаткової перевірки можна використати команду curl із заголовками. Перевіряйте як головну сторінку, так і сторінки з формами, адмінку, статичні ресурси та відповіді після перенаправлень. Якщо сайт працює через CDN, перевірка має виконуватися ззовні, через публічний домен.

• Переконайтеся, що кожен заголовок присутній лише один раз.
• Перевірте консоль браузера на повідомлення про заблоковані ресурси або порушення політик.
• Протестуйте сайт у режимі без кешу та після очищення кешу CDN.
• Перевірте мобільну версію, авторизацію, форми, попапи та інтерактивні елементи.
• Після впровадження спостерігайте за журналами сервера та повідомленнями користувачів.

curl -I https://example.com/

Додаткові заголовки та типові помилки

Після базового набору можна розглянути HSTS — Strict-Transport-Security. Він змушує браузер використовувати HTTPS, але додавати його слід лише після повного переходу сайту на HTTPS. Усі піддомени, ресурси та службові адреси мають коректно працювати через захищене з’єднання. Не вмикайте довгий термін дії або параметр preload без окремої перевірки наслідків.

Старий заголовок X-XSS-Protection не є сучасною заміною CSP і зазвичай не повинен бути основою захисту. Також не варто бездумно додавати десятки заголовків із готових чеклістів: помилкові або застарілі правила ускладнюють діагностику й можуть пошкодити функціональність сайту.

• Не плутайте X-Frame-Options із CSP-директивою frame-ancestors: вони вирішують подібні, але не тотожні завдання.
• Не вважайте зелений замок HTTPS доказом повної безпеки WordPress.
• Не тестуйте зміни одразу на робочому сайті, якщо є staging-копія.
• Не забувайте про оновлення ядра, теми та плагінів, сильні паролі, 2FA, резервні копії та мінімальні права доступу.