🔒 Безпека WordPress у 2026 році: повне керівництво із захисту сайту

Сайт на WordPress зламують не тому, що рушій «дірявий». Його зламують тому, що власник відклав оновлення плагіна, встановив пароль admin123 і не закрив xmlrpc.php. Автоматизовані боти сканують інтернет безперервно.

Їм байдуже, продаєте ви handmade-свічки чи керуєте інтернет-магазином. Вразливість знайдуть і використають. Брутфорс логінів, SQL-ін'єкції, заливка шела через дірявий плагін, усе це триває цілодобово.

Хороша новина: базовий захист можна вибудувати за вечір, без глибоких технічних знань. Нижче, перевірений набір заходів від встановлення файрвола до ручного загартування сервера. Усе, що описано, ми застосовуємо на своїх проєктах.

💡 Швидкий огляд:

• Встановіть файрвол: BBQ або Wordfence, перша лінія оборони блокує більшість атак ще до WordPress.
• Закрийте типові точки входу: xmlrpc.php, REST API для неавторизованих, лістинг директорій, редактор файлів в адмінці.
• Налаштуйте автоматичні оновлення ядра, тем і плагінів. Застаріла версія плагіна, головний вектор зламу.
• Зробіть бекап, який зберігається ПОЗА сервером. Без бекапа відновлення після зламу — це перевстановлення WordPress з нуля.
• Увімкніть двофакторну автентифікацію для всіх адміністраторів. Пароль можна підібрати, другий фактор, ні.

Куди б'ють у першу чергу: типові вектори атак

Більшість уявляє хакера як людину перед терміналом, яка вручну підбирає пароль до адмінки. Реальність нудніша: практично всі атаки виконують боти за скриптом. Вони шукають відомі вразливості в плагінах і темах, стукаються в xmlrpc.php, сканують /wp-content/uploads/ на наявність виконуваних PHP-файлів.

Головні вектори атак на WordPress:

• Застарілі плагіни та теми. За звітами Sucuri, близько 40% зламаних сайтів на момент зараження використовували застарілу версію CMS, плагіна або теми. Розробники закривають діри патчами, але тільки якщо ви ці патчі застосували.

• Слабкі паролі. Брутфорс-атаки перебирають десятки тисяч комбінацій за хвилину. Пароль із 6 символів без спецсимволів підбирається миттєво.

• Небезпечний хостинг. Дешевий shared-хостинг економить на ізоляції акаунтів: якщо сусідній сайт на сервері зламано, атака може перекинутися на ваш.

• Нульові права на запис. Коли вебсервер може писати в будь-який файл, залитий через діру шел отримує повний контроль над сайтом.

Розуміння цих векторів, половина захисту. Друга половина, конкретні дії.

Рівень 1: швидкий захист, який ви встановите за пів години

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

Встановіть файрвол: BBQ Firewall

BBQ Firewall, плагін від Jeff Starr, що працює за принципом «встановив і забув». Жодних налаштувань, жодного втручання в .htaccess або базу даних. Просто блокує шкідливі URL-запити до того, як вони доберуться до WordPress: eval(), base64_decode, надмірно довгі рядки, спроби ін'єкцій.

Плагін важить менше 10 КБ і не створює навантаження. При цьому ловить SQL-ін'єкції, XSS, заливку виконуваних файлів та атаки через «поганих» реферерів.

На практиці BBQ часто ставлять ПОВЕРХ Wordfence або Solid Security, вони вирішують різні задачі та не конфліктують. Файрвол рівня запитів плюс повноцінний security-плагін дають ешелонований захист.

Увімкніть двофакторну автентифікацію

Пароль можна підібрати, перехопити або купити в дампі злитих баз. Другий фактор, одноразовий код із застосунку-автентифікатора, ламає всю математику брутфорсу.

Вбудованої 2FA в WordPress немає. Найпростіший шлях, встановити Solid Security (колишній iThemes Security) або Wordfence. Обидва включають 2FA в безкоштовній версії. Після активації зайдіть у Security → Settings → Two-Factor Authentication і ввімкніть для ролі Administrator.

Ці ж плагіни закривають ще десяток вразливостей «з коробки»:

• Solid Security: змінює URL входу (/wp-admin → ваш унікальний), встановлює ліміт спроб логіну, сканує файли на зміни, блокує IP після серії невдалих входів, перевіряє плагіни та теми на відомі вразливості.

• Wordfence: Web Application Firewall з правилами, що автоматично оновлюються, сканер шкідливого коду, захист від брутфорсу, моніторинг трафіку в реальному часі. Особливо добрий для чищення вже зламаного сайту: знаходить бекдори, змінені файли ядра, прихований спам.

Достатньо ОДНОГО з них. Ми на своїх проєктах ставимо Wordfence + BBQ: перший дає WAF і сканер, другий відсікає сміттєві запити ще на підльоті.

Вимкніть xmlrpc.php

XML-RPC, інтерфейс для віддаленої роботи з WordPress через мобільні застосунки та трекбеки. Сьогодні він не потрібен переважній більшості сайтів, але залишається однією з найбільш атакованих точок: через xmlrpc.php боти брутфорсять паролі та проводять DDoS-атаки.

Вимкнути можна двома способами. Швидкий, через плагін: Solid Security робить це в один клік. Правильний, на рівні сервера, в .htaccess:

1
<Files xmlrpc.php>
2
Order Deny,Allow
3
Deny from all
4
</Files>

Додайте цей блок у кореневу .htaccess і забудьте про xmlrpc. Якщо користуєтеся мобільним застосунком WordPress або зовнішніми сервісами, яким потрібен XML-RPC, спочатку перевірте, чи працюють вони без нього. У 2026 році альтернативи, REST API з автентифікацією, закривають майже всі сценарії.

Закрийте лістинг директорій

Відкрийте в браузері вашсайт.com/wp-content/uploads/. Якщо бачите список файлів, у вас проблема. Лістинг директорій показує структуру сайту будь-кому, хто забажає.

Рішення: один рядок у .htaccess:

1
Options -Indexes

Заодно додайте порожній index.php у кожен підозрілий каталог: /wp-content/uploads/, теми, плагіни без власного index.php.

Вимкніть редактор файлів в адмінці

У WordPress з коробки можна правити .php-файли тем і плагінів прямо з адмінки: Appearance → Theme File Editor та Plugins → Plugin File Editor. Зручно, поки в адмінку не зайшов сторонній. Тоді це готовий інструмент для заливання шела.

Додайте в wp-config.php одну константу:

1
define('DISALLOW_FILE_EDIT', true);

Усе. Редактор зникає з адмінки. Для редагування файлів використовуйте FTP/SFTP, менш зручно, але безпечніше.

Рівень 2: ручне загартування WordPress

Наступні заходи трохи глибші: потребують редагування конфігураційних файлів і розуміння структури сервера. Результат, сайт, який боти оминають, бо не бачать у ньому WordPress.

Оновіть солі безпеки

Солі, security keys і salts, — це вісім рядків у wp-config.php, які шифрують cookie автентифікації. Змінити їх означає миттєво розлогінити всіх, зокрема потенційного зловмисника з викраденою сесією.

Перейдіть на api.wordpress.org/secret-key/1.1/salt/, скопіюйте згенерований блок і замініть ним відповідну ділянку у wp-config.php. Це займе хвилину. Робіть щоразу, коли є підозра на компрометацію.

Змініть префікс таблиць бази даних

Типово всі таблиці WordPress називаються wp_posts, wp_users і wp_options. SQL-ін'єкції часто заточені саме під стандартний префікс.

Під час свіжого встановлення вкажіть нестандартний префікс у wp-config.php:

1
$table_prefix = 'wp83x_';

Для наявного сайту змінити складніше: потрібно перейменувати таблиці в БД і оновити значення в usermeta та options. Без упевненого володіння phpMyAdmin і SQL не беріться, ризик обвалити сайт занадто високий.

Перенесіть wp-config.php вище кореня

wp-config.php містить пароль бази даних і ключі шифрування. Якщо вебсервер помилково віддасть його як текст, а таке трапляється під час кривого оновлення PHP, зловмисник отримує все.

Рішення: перемістіть wp-config.php на один рівень вище кореневої директорії сайту, наприклад із /public_html/ у домашню папку хостингу. WordPress автоматично шукає конфіг у батьківському каталозі, код не зламається.

Приховайте версію WordPress

Генератор <meta name="generator" content="WordPress X.X.X"> у вихідному коді сторінки, подарунок для ботів. Вони звіряють версію з базою відомих уразливостей і б'ють прицільно.

Приберіть генератор через functions.php:

1
// Видаляємо мета-тег генератора WordPress з вихідного коду сторінки
2
function no_generator() {
3
    return '';
4
}
5
add_filter('the_generator', 'no_generator');

Функція no_generator() повертає порожній рядок замість стандартного виведення версії. Фільтр the_generator перехоплює виведення метатегу та всіх його варіацій для фідів, RSS і REST API.

Заодно видаліть readme.html і liesmich.html із кореня встановлення, вони теж видають версію. Після оновлення WordPress ці файли можуть з'явитися знову, перевіряйте раз на місяць.

Налаштуйте HTTP Security Headers

HTTP-заголовки відповіді сервера повідомляють браузеру, як поводитися з контентом. Правильно налаштовані security headers блокують клікджекінг, XSS і підміну контенту.

Мінімальний набір для WordPress, додайте ці рядки до .htaccess:

1
Header set X-Frame-Options "SAMEORIGIN"
2
Header set X-Content-Type-Options "nosniff"
3
Header set Referrer-Policy "strict-origin-when-cross-origin"
4
Header set X-XSS-Protection "1; mode=block"

Плагін HTTP Headers дає змогу зробити те саме через адмінку, якщо не хочете чіпати конфігурацію сервера.

Для просунутого налаштування використовуйте Content Security Policy. Але врахуйте: неправильний CSP ламає адмінку, підвантаження шрифтів і роботу плагінів. Вводьте поступово, починаючи з режиму Content-Security-Policy-Report-Only.

Обмежте файлові права

Права доступу, останній рубіж. Якщо зловмисник залив файл, але не може його виконати, атака захлинулася.

Базові правила:

• Директорії: 755, власник читає, пише, виконує; група та решта читають і виконують.
• Файли: 644, власник читає і пише, решта тільки читають.
• wp-config.php: 400, тільки власник читає.
• .htaccess: 444, тільки читання для всіх, якщо WordPress не править його автоматично.

Категорично уникайте 777. Так, деякі плагіни просять 777 на wp-content/uploads/. Не давайте. 755 на папку і 644 на файли всередині достатньо для завантаження медіафайлів.

Що робити, якщо сайт уже зламано

Злам виявляють по-різному: редірект на казино, розсилання спаму, банер «Сайт може бути зламаний» у видачі Google, скарга хостера. Порядок дій:

• Негайно змініть усі паролі: адмінка WordPress, FTP/SFTP, база даних, панель хостингу. Почніть з останнього. Якщо хакер у панелі хостингу, він просто створить нового адміна.

• Відновіть сайт із бекапу, зробленого ДО зламу. Свіжий бекап, зроблений після компрометації, з високою ймовірністю містить бекдор. Якщо бекапу немає, наступний крок.

• Встановіть Wordfence і запустіть повне сканування. Плагін знайде змінені файли ядра, підозрілий код, приховані бекдори. Видаліть усе, що позначив сканер, потім замініть ядро WordPress свіжою копією: кнопка «Re-install» у Dashboard → Updates.

• *Перевірте wp-content/uploads/ на наявність .php-файлів.* Їм там не місце. Будь-який .php у папці завантажень, майже гарантовано шел.

Подивіться відео вище, у ньому розібрано типові помилки безпеки WordPress і способи їх виправлення, від слабких паролів до неправильних прав доступу.

• Підключіть зовнішній моніторинг. Sucuri, хмарний сервіс із WAF та командою реагування. WAF фільтрує трафік до сервера. У разі зламу команда Sucuri очищає сайт за кілька годин. Ціна від $199 на рік за базовий тариф з очищенням і моніторингом. Не безплатно, але коли сайт приносить гроші, простій обходиться дорожче.

Обов’язково зареєструйте сайт у Google Search Console. Якщо Google помітить шкідливий код, ви отримаєте сповіщення до того, як сайт випаде з видачі.

Захист від вимагачів: чому бекап вирішує все

Ransomware шифрує файли сайту та вимагає викуп. WordPress-сайти, часта ціль: замовлення, клієнтська база, контент. Втратити все за одну ніч, реальний сценарій без бекапу.

Три правила:

• Бекап поза сервером. Хмара або окремий FTP. UpdraftPlus і Duplicator автоматизують вивантаження.
• Фаєрвол і сканер. Wordfence + BBQ відсікають заливку шкідливого файлу на етапі запиту.
• Джерела тільки офіційні. Каталог WordPress.org і сайти розробників із репутацією. Жодних «безплатних» тем із торентів.

Автоматичний моніторинг цілісності файлів

Серверний захист, не разова акція. Зберіть перевірки в shell-скрипт на cron, раз на добу, результат на пошту:

1
SITE_ROOT="/absolute/path/to/public_html"
2
 
3
find "$SITE_ROOT" -mtime -1 -name "*.php" \
4
    -printf '%TY-%Tm-%Td %TT\t%p\n' >> /tmp/file-changes.log
5
 
6
find "$SITE_ROOT" -mtime -7 -name "*.php" \
7
    | xargs grep -l -i "eval\|base64_decode\|iframe\|file_get_contents" \
8
    >> /tmp/suspicious-code.log
9
 
10
find "$SITE_ROOT/wp-content/uploads" -name "*.php" -print \
11
    >> /tmp/php-in-uploads.log
12
 
13
find /home -type d -perm 0777 >> /tmp/perms.log
14
find /home -type f -perm 0777 >> /tmp/perms.log
15
 
16
mailx -s "Webserver File Audit $(date +%F)" admin@example.com \
17
    < /tmp/suspicious-code.log

Скрипт запускається раз на добу через cron. Перший блок find -mtime -1 показує PHP-файли, що змінювалися за останні 24 години, головний детектор вторгнень. Другий шукає сигнатури шелів: eval, base64_decode, приховані iframe. Третій ловить PHP у папці завантажень, легітимного PHP там не буває. Четвертий знаходить файли та папки з правами 777. Результат надходить на пошту. Профілактика ловить вторгнення на ранній стадії, до того як Google помітить і забанить сайт у видачі.

Sucuri: хмарний фаєрвол, коли немає часу возитися

Принцип роботи: трафік проходить через хмарний проксі Sucuri з WAF, шкідливі запити відсікаються до хостингу. Сайт завантажується швидше завдяки CDN. Ключові можливості: WAF із сигнатурами реального часу, захист від DDoS, автоочищення від malware.

Тарифи від $199 на рік. Безплатної версії немає, але плагін-сканер Sucuri перевіряє файли на зміни без WAF. Для комерційного сайту, виправдана інвестиція. Для особистого блогу вистачить Wordfence + BBQ.

⁉️🤔 Часті запитання

Чи безпечний WordPress сам по собі?

Ядро WordPress перевіряють сотні розробників та аудиторів безпеки. Проблема не в ядрі, проблема в застарілих плагінах, темах із неперевірених джерел і паролях 123456. Регулярні оновлення плюс базовий файрвол дають достатній захист для більшості сайтів.

Чи можна обійтися без плагінів безпеки?

Можна, якщо ви готові вручну налаштовувати файрвол на рівні сервера: iptables, mod_security, 7G/8G Firewall у .htaccess, відстежувати CVE для кожного плагіна й писати cron-скрипти для моніторингу. Для всіх інших встановлення Wordfence або Solid Security, година проти десятків годин ручної роботи.

Чи потрібні оновлення, якщо стоїть файрвол?

Так, обов’язково. Файрвол відсікає атаки «ззовні», але якщо встановлено плагін із відомою вразливістю, рано чи пізно знайдеться вектор, який файрвол не перехопить. Оновлення всіх компонентів WordPress — це база, без якої інші заходи працюють напівсили.

Який плагін безпеки обрати?

Для мінімального захисту: BBQ Firewall, блокує шкідливі URL-запити, нуль налаштувань. Для повного захисту: Wordfence, WAF, сканер, 2FA, захист від брутфорсу, все в безплатній версії. Зв’язка BBQ + Wordfence перекриває обидва рівні без конфліктів.

Що робити з REST API, закривати?

REST API потрібен WordPress для роботи редактора блоків Gutenberg, низки плагінів і зовнішніх інтеграцій. Повне вимкнення зламає адмінку. Натомість обмежте доступ: неавторизованим користувачам залиште тільки публічні ендпоїнти. Плагін REST API Toolbox дає змогу гнучко налаштувати доступ без хірургічного втручання.

Як часто перевіряти сайт на віруси?

Автоматично, щодня через cron-скрипти: перевірка змінених файлів, пошук .php в uploads. Вручну, раз на місяць: зайти в Wordfence, запустити повне сканування, перевірити список плагінів на предмет занедбаних. Немає оновлень понад рік, видалити або замінити.

Чи можна втратити позиції в Google через злам?

Можна, і швидко. Google сканує сайти на шкідливий код і позначає заражені попередженням у видачі. Якщо злам не усунути за кілька тижнів, сайт деіндексують. Зареєструйте сайт у Google Search Console, отримаєте сповіщення про проблему одразу після виявлення.

Чи допоможе зміна хосту від зламів?

Частково. Якісний хостинг додає свої рівні: ізоляція акаунтів, моніторинг мережі, автооновлення PHP. Але хостинг не захищає від дірявого плагіна, який ви поставили самі, і від пароля qwerty. Безпека — це листковий пиріг: хостинг плюс оновлення плюс файрвол плюс права доступу плюс бекапи.

Безпека WordPress: з чого почати просто сьогодні

Головне правило безпеки WordPress, не намагатися осягнути неосяжне за один раз. Почніть із трьох кроків:

• Якщо немає файрвола, поставте BBQ Firewall. Одна хвилина.
• Якщо немає бекапів поза сервером, налаштуйте UpdraftPlus із вивантаженням у хмару. Десять хвилин.
• Якщо не ввімкнено 2FA для адміністраторів, увімкніть через Wordfence. П’ять хвилин.

Далі повертайтеся до списку вище: закрийте xmlrpc, оновіть солі, вимкніть редактор файлів, налаштуйте security headers. По одному пункту на день, і через тиждень сайт буде захищений на порядок краще, ніж учора.

А які заходи безпеки вже працюють на вашому сайті? Напишіть у коментарях, цікаво порівняти підходи.