Сайт может использовать HTTPS и при этом оставаться недостаточно защищённым на стороне браузера. Между сервером и экраном пользователя HTTP-заголовки передают инструкции, ограничивающие потенциально опасные действия: загрузку внешних скриптов, встраивание сайта в iframe, неверную интерпретацию типа файла или доступ к чувствительным функциям браузера. Эти меры почти незаметны, однако их следует включать в технический аудит сайта на WordPress, PHP-приложения или специализированной CRM.

Для чего нужны защитные HTTP-заголовки?

Заголовок ответа представляет собой информацию, которую сервер отправляет вместе со страницей. Некоторые заголовки указывают браузеру, что разрешать, а что блокировать. Они могут снизить последствия внедрения скриптов, кликджекинга или эксплуатации содержимого с неверно указанным типом. OWASP рассматривает такие заголовки как полезный дополнительный уровень защиты, а не как замену правильно разработанному, обновляемому и проверяемому коду.

Какие меры защиты стоит проверить в первую очередь

  • Content-Security-Policy (CSP) определяет разрешённые источники скриптов, стилей, изображений, шрифтов и других ресурсов. Грамотно настроенная политика, в частности, затрудняет эксплуатацию некоторых XSS-уязвимостей. При этом её необходимо адаптировать к конкретному сайту.
  • Strict-Transport-Security (HSTS) предписывает браузеру автоматически использовать HTTPS при последующих посещениях. Этот заголовок должен передаваться только через HTTPS. Параметр includeSubDomains следует включать лишь в том случае, если все соответствующие поддомены могут постоянно работать по HTTPS.
  • X-Content-Type-Options: nosniff не позволяет браузеру самостоятельно определять тип содержимого, отличный от объявленного сервером. Это снижает риск сценариев, при которых файл интерпретируется как исполняемый код.
  • frame-ancestors в составе CSP определяет, какие сайты могут встраивать страницу. X-Frame-Options остаётся полезным для совместимости с некоторыми старыми браузерами, однако frame-ancestors обеспечивает более современное управление.
  • Referrer-Policy ограничивает сведения об исходной странице, передаваемые при переходе пользователя по ссылке. Permissions-Policy позволяет отключать или ограничивать камеру, микрофон, геолокацию и другие функции, когда они не нужны.

Почему готовая конфигурация может нарушить работу сайта

Слишком строгая CSP может заблокировать систему аналитики, карту, видео, онлайн-оплату, капчу или скрипт, добавленный WordPress. И наоборот, политика с большим количеством исключений, например unsafe-inline, частично теряет смысл. Правильный подход состоит в том, чтобы сначала составить перечень реально используемых ресурсов, а затем протестировать политику в режиме Content-Security-Policy-Report-Only. В этом режиме нарушения регистрируются, но соответствующие элементы не блокируются сразу.

HSTS также требует осторожности. Большой срок действия, параметр includeSubDomains или включение домена в список предварительной загрузки могут сделать поддомен недоступным, если его сертификат или HTTPS-конфигурация ещё не готовы. Лучше начать с небольшого срока, проверить весь домен, а затем постепенно усиливать правило.

Как провести практическую проверку

Первичную проверку можно выполнить во вкладке «Сеть» инструментов разработчика браузера или с помощью команды, отображающей HTTP-заголовки. Следует проверить главную страницу, административную часть, формы, личный кабинет и, при наличии, процесс оплаты.

  • Зафиксировать уже передаваемые заголовки и выявить дублирование или противоречия.
  • Составить список внешних доменов, ресурсы которых загружает сайт.
  • Подготовить правила в тестовой среде или в режиме отчёта.
  • Проверить формы, аналитику, карты, видео, авторизацию и оплату.
  • Внедрять изменения постепенно и отслеживать ошибки после публикации.

В WordPress отдельные заголовки можно добавить с помощью плагина, однако настройка на уровне сервера, обратного прокси или CDN часто оказывается более последовательной. Главное, чтобы разные уровни не отправляли противоречащие друг другу правила. В специализированном PHP-приложении заголовки следует задавать в общей конфигурации, охватывающей все ответы, включая страницы ошибок.

Небольшая настройка, требующая системного подхода

Защитные заголовки не делают сайт неуязвимым. Они создают дополнительный уровень защиты вокруг кода, обновлений, резервного копирования, контроля доступа и мониторинга. Для малого или среднего предприятия в Ницце, Каннах или Монако задача состоит не в накоплении технических правил, а в защите важных пользовательских сценариев: обращений, бронирований, платежей, доступа клиентов и внутренних инструментов.

Что проверить перед публикацией

Перед публикацией ещё раз сверить рекомендации OWASP и MDN, проверить актуальную совместимость Permissions-Policy и CSP, убедиться, что все поддомены поддерживают HTTPS до включения HSTS с параметрами includeSubDomains или preload, а также адаптировать каждое правило к внешним сервисам, которые действительно использует сайт.