Власник магазину зазвичай дізнається про проблеми з безпекою одним із двох способів: дзвінком від хостингу «у вас на сайті шкідливий код» або скаргою клієнта, що з картки списали гроші вже після оплати на сайті. Третій варіант, на жаль, трапляється рідко – злам майже ніколи не виглядає як спливаюче вікно з черепом і кістками. Найчастіше це просто трохи повільніший сайт, дивна папка в /wp-content/uploads з файлами .php, і позиції в Google, які повільно сповзають вниз, бо магазин непомітно роздає посилання на казино чи фарма-сайти.
WordPress сам по собі – не дірявий движок. Дірявими зазвичай виявляються плагіни, теми і звички адміністратора. Розберемо, де саме магазини на WooCommerce найчастіше ламаються і що з цим реально робити, без загальних порад «оновлюйте все вчасно».
Застарілі плагіни й теми – найпопулярніший вхід
На сайтах, які вже зламали, картина часто знайома: старий слайдер, покинутий шаблон з нульованого маркетплейсу, або плагін-калькулятор доставки, який автор перестав оновлювати три роки тому. Уразливість публікують у базі на кшталт WPScan – і за кілька днів боти вже сканують інтернет у пошуках сайтів із такою ж версією плагіна.
Практично це означає: раз на тиждень – перевірка списку плагінів на «потребує оновлення», видалення всього, що не використовується (деактивований плагін – це той самий код на диску, він так само вразливий), і окрема увага до нульованих (nulled) тем і плагінів. Піратська версія платного плагіна майже завжди містить бекдор, вшитий тим, хто її «зламав» – це не міський міф, а типова знахідка під час чистки заражених сайтів.
Слабкий пароль адміністратора і відсутність двофакторки
Логін admin і пароль на кшталт назви магазину плюс 2026 – досі не рідкість. Брутфорс-боти перебирають саме такі комбінації тисячами за годину, і їм не потрібен розум, потрібен лише час.
- Змінити логін адміністратора з admin на щось неочевидне – завести окремого користувача, старого видалити чи понизити в правах.
- Увімкнути двофакторну автентифікацію – плагіни Wordfence Login Security чи miniOrange 2FA налаштовуються за 10 хвилин.
- Обмежити кількість спроб входу – Limit Login Attempts Reloaded або аналогічна функція в security-плагіні.
Окремо – паролі співробітників, які мають доступ до адмінки чи FTP. Один слабкий пароль менеджера, який заводить товари, зводить нанівець всю решту захисту.
Форми завантаження файлів без обмежень
Уявіть форму «Завантажити фото для відгуку» чи «Прикріпити файл до заявки на повернення» – зручна річ для клієнта. Але якщо плагін чи кастомний код не перевіряє розширення файлу і сервер дозволяє виконувати PHP у папці uploads, зловмисник завантажує не фото, а веб-шелл – маленький php-файл, який дає повний контроль над сайтом через звичайний браузер.
Закривається це на двох рівнях. На рівні плагіна – білий список дозволених розширень (jpg, png, pdf), а не чорний список заборонених. На рівні сервера – заборона виконання PHP у /wp-content/uploads/ через правило в .htaccess або конфіг Nginx. Це п’ять хвилин роботи, які закривають цілий клас атак.
wp-config.php, debug-режим і чужі очі
Файл wp-config.php містить паролі до бази даних відкритим текстом. Він не повинен бути доступний ззовні в принципі, але трапляється, що після невдалого перенесення сайту чи бекапу з’являється wp-config.php.bak чи wp-config.php~ – а такі файли сервер віддає як звичайний текст, не як PHP-код.
Другий момент – режим WP_DEBUG, залишений увімкненим на робочому сайті «щоб побачити помилку». Він виводить шляхи на сервері, назви таблиць, іноді фрагменти коду просто у браузер будь-якого відвідувача. Перевірте один раз: WP_DEBUG має бути false на проді, а лог помилок – писатися у файл, недоступний ззовні, а не на екран.
Уразливості в коді плагінів – SQL-ін’єкції та XSS у відгуках
Тут вже складніше, бо це не питання налаштувань, а якості чужого коду. Плагін для відгуків, який вставляє текст користувача в запит до бази без екранування, – класична SQL-ін’єкція, через яку можна витягнути всю таблицю замовлень разом з адресами й телефонами клієнтів. Плагін, який виводить коментар «як є», без очищення від тегів, відкриває XSS: зловмисник лишає у відгуку не текст, а скрипт, який виконається в браузері наступного відвідувача чи навіть адміністратора, коли той модерує коментарі.
Повністю виключити ризик, якщо на сайті стоять сторонні плагіни, неможливо. Але можна суттєво знизити ймовірність: обирати плагіни з активною підтримкою і великою кількістю встановлень, дивитися на дату останнього оновлення перед встановленням, і поставити security-плагін з функцією virtual patching (Wordfence це вміє) – він блокує типові патерни атак на рівні запиту, ще до того, як вразливий код у плагіні встигне його обробити.
Брутфорс-спроби входу і чому rate-limit не панацея
Навіть без вразливостей у коді сайт можна покласти простим перебором – тисячі запитів на wp-login.php за хвилину з’їдають ресурси хостингу і, рано чи пізно, підбирають слабкий пароль. Обмеження спроб входу – це мінімум, не рішення. Реальний захист – сховати wp-login.php від прямого доступу (плагіни на кшталт WPS Hide Login дозволяють задати свій URL для входу), додати CAPTCHA на форму, і винести захист на рівень до сервера – через firewall хостингу чи Cloudflare.
REST API та XML-RPC – точки, про які забувають
WordPress REST API за замовчуванням віддає список користувачів сайту через /wp-json/wp/v2/users/ – включно з логінами адміністраторів, навіть якщо display name інший. Це готовий список для брутфорсу, і його часто не закривають просто тому, що ніхто не перевіряв, як API взагалі поводиться.
XML-RPC – ще старіший протокол, яким майже ніхто вже не користується (крім, іноді, мобільного застосунку для публікації постів), але який залишається увімкненим за замовчуванням і активно використовується для того самого брутфорсу, тільки в обхід звичайних лімітів на wp-login.php. Якщо не публікуєте пости через мобільний застосунок і не маєте інтеграцій, які вимагають XML-RPC, – вимикайте його повністю через .htaccess чи плагін.
HTTPS, мішаний контент і платіжні форми
SSL-сертифікат сьогодні є майже в усіх, і про сам факт HTTPS вже мало хто забуває. А от про мішаний контент – так: коли сторінка завантажується по https, але картинка чи скрипт підвантажується по http, браузер підсвічує це як небезпечне з’єднання, і частина клієнтів на цьому місці закриває вкладку, особливо на сторінці оплати.
Окрема історія – платіжні форми та інтеграції з еквайрингом. Якщо форма оплати вбудована безпосередньо на сайт, а не редіректить на сторінку банку чи платіжного провайдера, сайт формально підпадає під вимоги PCI DSS, і зберігати чи навіть тимчасово логувати номери карток на своєму сервері – пряма дорога до штрафів і втрати довіри еквайра. Правильна практика – hosted-форма оплати чи iframe від провайдера, коли дані картки взагалі не проходять через ваш сервер.
Бекапи, staging і план на випадок, якщо все ж зламали
Навіть при ідеальному захисті варто виходити з того, що рано чи пізно щось піде не так – новий 0-day у популярному плагіні, людський фактор, дірка в самому хостингу. У цьому випадку рятує не антивірус, а бекап, зроблений до інциденту і перевірений на відновлюваність.
- Автоматичний бекап бази і файлів щодня, зі зберіганням поза основним сервером (UpdraftPlus з вивантаженням у хмару, а не тільки в ту саму папку на диску).
- Тестове відновлення бекапу раз на квартал – бекап, який жодного разу не відновлювали, з однаковою ймовірністю може виявитись порожнім архівом.
- Оновлення плагінів і теми – спочатку на staging-копії сайту (WP Staging чи аналог у хостингу), і тільки після перевірки – на проді. Це закриває і безпекові інциденти від самого оновлення, і банальні конфлікти плагінів.
Якщо злам вже стався – перше, що робити, це не панічно видаляти файли, а знімати сайт з публічного доступу (maintenance mode чи повне відключення), міняти всі паролі – адмінки, бази, FTP, хостинг-панелі, – і вже потім розбиратися, що саме потрапило в систему і як довго воно там сиділо.
Жодна з цих речей окремо не займає багато часу. Проблема зазвичай не в складності, а в тому, що жодного пункту зі списку вище ніхто не закрив від початку – сайт запустили, магазин почав продавати, і на «зробимо безпеку пізніше» так і не дійшли руки. Найпростіший спосіб зрушити з місця – не намагатись зробити все відразу, а закрити один пункт цього тижня: увімкнути 2FA собі й менеджерам. Решта підтягнеться.
Читайте також: План оновлень на рік: щоб не зламати сайт у сезон; «Сайт ліг у сезон»: як побудувати стабільність і SLA, щоб не втрачати гроші.
