Заголовки безопасности 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 разрешает открывать страницы во фрейме только в пределах того же источника. Заголовок защищает от многих сценариев 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, резервных копиях и минимальных правах доступа.