Пароль не є єдиним фактором захисту облікового запису WordPress. Після входу браузер отримує cookie авторизації, яка підтверджує активну сесію. Якщо зловмисник отримає її значення, він у деяких випадках зможе діяти від імені користувача без повторного введення пароля.
Тому важливо перевірити не лише складність пароля, а й умови, за яких cookie створюється, передається та зберігається. Нижче — практичний чекліст для WordPress, wp-admin і сайтів, де використовуються Elementor, AJAX-запити або зовнішні інтеграції.
Які 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, доступна для всіх піддоменів, має більшу зону впливу. Якщо немає об'єктивної потреби ділитися сесією між піддоменами, краще не розширювати область дії.
Не слід встановлювати HttpOnly для cookie, яку справді має читати JavaScript. Але авторизаційні cookie WordPress не повинні бути доступними скриптам без вагомої причини. Зміни потрібно тестувати в окремому вікні браузера після видалення старих cookie.
Кешування сторінок, CDN і правила безпеки WAF також можуть впливати на авторизацію. Адмін-панель, сторінка входу та персоналізовані запити не повинні віддаватися користувачам із загального кешу.
- Не копіюйте конфігурацію cookie з іншого сайту без перевірки його архітектури.
- Не вимикайте захист лише тому, що інтеграція працює нестабільно.
- Після змін перевіряйте мобільний браузер, різні доменні варіанти та всі критичні форми.
- Оновлюйте WordPress, Elementor, теми й плагіни: безпечні cookie не виправляють уразливий код.
Поширені запитання
Чи достатньо атрибута Secure для захисту cookie WordPress?
Ні. Secure захищає передачу cookie від використання через HTTP, але не вирішує проблеми XSS, викраденого пристрою, слабких паролів або уразливого плагіна. Потрібні також HttpOnly, коректний SameSite, HTTPS, оновлення та контроль доступу.
Чи можна встановити SameSite=Strict для всіх cookie сайту?
Не завжди. Strict може вплинути на зовнішні переходи, SSO, платежі та інші інтеграції. Для авторизаційної сесії політику потрібно підбирати після тестування, а cookie сторонніх сервісів не слід змінювати без розуміння їхнього призначення.
Що робити, якщо після HTTPS cookie або вхід перестали працювати?
Очистіть старі cookie, перевірте адресу WordPress і сайту, редиректи, налаштування reverse proxy та кешування. Також перевірте, чи не виникає цикл перенаправлень і чи правильно сервер визначає оригінальний HTTPS-запит.
Чи потрібно видаляти всі cookie після зміни пароля?
Користувачеві варто завершити всі інші активні сесії WordPress, особливо після підозрілої активності. Локальні cookie можна очистити додатково, але цього недостатньо, якщо сесії вже викрадені або доступ до сайту отримав сторонній користувач.
Висновок
Безпечна конфігурація cookie для WordPress починається з повного HTTPS у вході та wp-admin, а далі перевіряється на рівні браузера: Secure, HttpOnly, SameSite, Domain, Path і термін дії. Окремо протестуйте Elementor, AJAX, медіафайли та зовнішні інтеграції.
Не змінюйте cookie навмання. Регулярно оновлюйте сайт, використовуйте окремі облікові записи з мінімальними правами, багатофакторну автентифікацію та завершуйте активні сесії після підозрілих подій.