Безопасные cookie для админ-панели WordPress: что проверить

Какие cookie использует WordPress

При входе WordPress создаёт авторизационные cookie для определения пользователя и его сессии. Их названия могут начинаться с wordpress_, а для защищённых соединений часто используются варианты с префиксом wordpress_sec_. Также могут создаваться cookie для комментариев, настроек или сторонних плагинов.

Значения cookie нельзя копировать, публиковать или передавать в чатах. Даже если значение выглядит как случайный набор символов, оно может быть ключом к активной сессии.

Для админ-панели особенно важны следующие атрибуты: Secure, HttpOnly и SameSite. Дополнительно стоит проверить Domain, Path, срок действия и способ завершения сессии.

• Secure — браузер отправляет cookie только по HTTPS.
• HttpOnly — JavaScript в браузере не может прочитать cookie через document.cookie.
• SameSite — определяет, будет ли cookie отправляться при переходах и запросах с внешних сайтов.
• Expires или Max-Age — определяют, как долго cookie остаётся действительной.
• Domain и Path — ограничивают сайты и URL-пути, для которых используется cookie.

Что означают Secure, HttpOnly и SameSite

Атрибут Secure нужен для того, чтобы авторизационная cookie не передавалась через обычный HTTP. Если сайт доступен и по адресу http://, и по адресу https:// без корректного перенаправления, часть запросов может оставаться незащищённой. Для админ-панели это недопустимо.

HttpOnly снижает риск кражи cookie через XSS-уязвимость: скрипт на странице не может напрямую прочитать такую cookie. Однако этот атрибут не устраняет саму XSS-проблему и не защищает от кражи сессии другими способами.

SameSite=Lax обычно является практичным компромиссом для обычного сайта: cookie отправляется при стандартных переходах на сайт, но ограничивается во многих межсайтовых запросах. SameSite=Strict обеспечивает более жёсткие ограничения, однако может повлиять на отдельные сценарии входа, переходы из писем или внешние интеграции.

Не все cookie сайта имеют одинаковые требования. Например, платёжному сервису, SSO, внешнему конструктору или виджету может потребоваться другая политика SameSite. Не изменяйте атрибуты массово, пока не проверите критические сценарии.

• Для cookie административной сессии должен быть включён Secure.
• Для авторизационных cookie желательно использовать HttpOnly.
• Начинайте с SameSite=Lax, если нет подтверждённой необходимости в Strict.
• Не путайте SameSite с полной защитой от CSRF: WordPress и плагины также используют nonce и проверки прав.

Как проверить cookie в браузере

Проводите проверку после входа именно в админ-панель, а не только на главной странице. Откройте инструменты разработчика браузера и перейдите в раздел Application или Storage, затем — в Cookies и к домену сайта. Названия вкладок могут немного различаться в разных браузерах.

Найдите авторизационные cookie WordPress и проверьте флаги Secure и HttpOnly, значение SameSite, домен, путь и время окончания действия. Само значение cookie не нужно просматривать или копировать для публикации.

Дополнительно откройте вкладку Network, обновите страницу wp-admin и просмотрите HTTPS-запросы. В заголовках запросов cookie не должна передаваться на HTTP-адреса. Если браузер показывает предупреждение о небезопасной передаче или блокировке cookie, сначала исправьте HTTPS и конфигурацию домена.

• Проверьте сайт с www и без www, если доступны оба варианта.
• Проверьте основной домен и поддомены, если админ-панель размещена отдельно.
• Выполните тест в приватном окне после очистки старых cookie.
• Проверьте вход, выход, открытие редактора Elementor, сохранение изменений и загрузку медиафайлов.

Проверка заголовков сервера

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

• Убедитесь, что HTTP-версия перенаправляет на HTTPS одной корректной цепочкой.
• Проверьте, не создаётся ли авторизационная cookie без Secure.
• Если перед WordPress работает CDN или reverse proxy, проверяйте заголовки на публичном домене, а не только на сервере.

curl -I https://example.com/wp-login.php

Как принудительно использовать HTTPS для входа и wp-admin

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

В стандартной конфигурации WordPress для защиты административной части можно использовать константы FORCE_SSL_ADMIN и FORCE_SSL_LOGIN в wp-config.php. Добавляйте их только после проверки того, что HTTPS корректно определяется на сервере и в reverse proxy.

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

• Не редактируйте wp-config.php без резервной копии и доступа к файловой системе.
• После изменения настроек проверьте выход из системы, повторный вход и работу wp-admin.
• Не оставляйте одновременно несколько канонических адресов админ-панели.
• Смешанные HTTP-ресурсы, ошибки прокси и кеширование могут выглядеть как проблема cookie, хотя причиной будет конфигурация HTTPS.

define( 'FORCE_SSL_ADMIN', true );
define( 'FORCE_SSL_LOGIN', true );

Срок действия сессии и завершение активных входов

Длительная сессия удобна, но увеличивает период, в течение которого украденная cookie может оставаться полезной. Администраторам стоит использовать более короткий и контролируемый срок входа, не сохранять сессию на общих или чужих устройствах и выходить из админ-панели после завершения работы.

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

Завершение сессий не заменяет расследование. При признаках взлома смените пароли WordPress, хостинга, FTP или SSH, базы данных и электронной почты, а также проверьте администраторов, плагины, темы и журналы входов.

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

Типичные ошибки при настройке cookie

Самая распространённая ошибка — попытка добавить Secure, HttpOnly или SameSite с помощью случайного плагина или фрагмента PHP-кода без понимания того, какие cookie создают WordPress, сервер и сторонние сервисы. Это может нарушить вход, AJAX-запросы, работу редактора Elementor, оплату или SSO.

Другая проблема — слишком широкий атрибут Domain. Cookie, доступная для всех поддоменов, имеет более широкую область воздействия. Если нет объективной необходимости делиться сессией между поддоменами, лучше не расширять область действия cookie.

Не следует устанавливать HttpOnly для cookie, которую действительно должен читать JavaScript. Однако авторизационные cookie WordPress не должны быть доступны скриптам без веской причины. Изменения нужно тестировать в отдельном окне браузера после удаления старых cookie.

Кеширование страниц, CDN и правила безопасности WAF также могут влиять на авторизацию. Админ-панель, страница входа и персонализированные запросы не должны отдаваться пользователям из общего кеша.

• Не копируйте конфигурацию cookie с другого сайта без проверки его архитектуры.
• Не отключайте защиту только потому, что интеграция работает нестабильно.
• После изменений проверяйте мобильный браузер, разные варианты домена и все критические формы.
• Обновляйте WordPress, Elementor, темы и плагины: безопасные cookie не исправляют уязвимый код.