Безпека структури папок WordPress: як заблокувати доступ до папки "wp-includes"

Безпека структури папок WordPress передбачає правильне обмеження доступу до папки "wp-includes" не шляхом повного блокування всієї папки, а забороною запуску PHP-файлів з неї та вимкненням індексації каталогу. Адже wp-includes містить необхідні для роботи ядра WordPress JavaScript, CSS та інші статичні файли; повне блокування папки може порушити дизайн сайту, роботу редактора або функції плагінів. Оптимальний підхід — це блокування безпосереднього запуску PHP через правила .htaccess для Apache або location у конфігурації Nginx, а також перевірка сайту на помилки з відповідями 403/404 та тестування критичних сторінок.

Одна з найпоширеніших помилок у безпеці WordPress — це покладатися лише на складні паролі та плагіни без додаткових налаштувань. Зловмисники, як правило, сканують каталоги з ядром, застарілі плагіни, неправильні права доступу та відкриту індексацію. Папка wp-includes — одна з основних цілей таких сканувань. У цьому матеріалі ви знайдете практичні поради, як обмежити доступ до wp-includes на реальних хостинг-серверах, які правила можуть викликати проблеми, приклади конфігурацій для Apache і Nginx, способи тестування й чекліст для підтримки безпеки. Для більш надійної роботи вашого сайту рекомендуємо також звернути увагу на WordPress хостинг та загальний рівень захисту з сертифікат SSL.

Що таке папка wp-includes і чому її варто захищати?

wp-includes — це одна з ключових папок ядра WordPress, у якій зберігаються базові бібліотеки, компоненти тем, блок-редактор, REST API, обробка медіа, класи, функції та різноманітні JavaScript-файли. Простими словами, wp-includes — це своєрідна "моторна" частина WordPress, яку користувачі не повинні безпосередньо відвідувати.

Звичайному відвідувачу не потрібно відкривати адресу типу site.com/wp-includes/. Водночас у вихідному коді сторінки можуть бути підключені деякі статичні ресурси з цієї папки, наприклад, стандартні скрипти WordPress, emoji-скрипти або компоненти редактора. Тому завдання безпеки — заборонити доступ до PHP-файлів, не блокуючи при цьому завантаження статичних ресурсів.

Ця різниця є основою професійного підходу до безпеки структури папок WordPress. Випадкове блокування всіх файлів у папці може призвести до появи "білої сторінки", некоректної роботи адмін-панелі, блок-редактора або спотворення дизайну. Мета — звузити поверхню атаки, зберігаючи при цьому необхідні для роботи сайту файли.

Які переваги дає блокування доступу до wp-includes?

Заборона запуску PHP-файлів у папці wp-includes не припинить усі атаки, але суттєво зменшить потенційні загрози. Особливо це важливо для сайтів, уражених шкідливим ПЗ, де зловмисники намагаються завантажити або викликати шкідливі PHP-скрипти у доступних каталогах. Заборона безпосереднього запуску PHP з wp-includes створює додатковий рівень захисту.

Цей захід дає такі переваги:

• Обмежує виклик PHP-файлів ядра за прямими URL.
• Допомагає приховати вміст папки, якщо увімкнена індексація.
• Зменшує витік інформації під час автоматичних сканувань ботами.
• Забезпечує захист на рівні веб-сервера навіть без плагінів безпеки.
• Підсилює багаторівневий захист у поєднанні з WAF, SSL, актуальною версією PHP та коректними правами доступу.

Важливо розуміти, що це лише один із рівнів захисту. Якщо у вас застарілі плагіни, слабкі паролі або скомпрометований FTP-акаунт, то лише блокування wp-includes не врятує від злому. Безпека — це комплекс заходів на рівні хостингу, програми, користувачів та регулярного обслуговування. Для надійного фундаменту рекомендуємо ознайомитись із Безпечний веб-хостинг та додатковими заходами з Безпека домену.

Поширені помилки при блокуванні wp-includes

Повне блокування папки

Найпоширеніша помилка — це заборона всіх HTTP-запитів до папки wp-includes через статус 403. На перший погляд це логічно, але WordPress завантажує частину статичних ресурсів саме звідси. В результаті блокування можуть з’явитися проблеми: блок-редактор не відкриється, JavaScript-файли не завантажаться, а на фронтенді з’являться дрібні, але критичні збої у відображенні.

Впровадження змін без тестування на staging

Навіть одна помилка у .htaccess або конфігурації Nginx може викликати помилку 500 Internal Server Error. Особливо ризиковано робити зміни одразу на сайтах із великою кількістю відвідувачів. Рекомендується спочатку зробити резервну копію файлу, протестувати правила на staging-середовищі, а потім плавно застосувати на продакшені. Якщо у вас є доступ до staging або автоматичного бекапу, наприклад у Hostragons, це варто використовувати — Резервне копіювання веб-хостингу.

Надмірна довіра до плагінів без правил сервера

Плагіни безпеки корисні, але правила на рівні веб-сервера блокують небажані запити раніше, ніж вони доходять до PHP. Це знижує навантаження на сервер і підвищує загальну безпеку. Тому навіть при використанні плагінів не варто ігнорувати базові правила .htaccess або Nginx.

Чекліст перед впровадженням

Щоб мінімізувати ризики, перед обмеженням доступу до wp-includes рекомендується виконати наступні кроки:

• Зробити резервну копію поточного .htaccess або конфігурації Nginx.
• Оновити ядро WordPress, теми та плагіни до останніх версій.
• Переконатися, що версія PHP підтримується і безпечна.
• Перевірити права доступу: папки мають бути 755, файли — 644.
• Переконатися, що критичні файли, як wp-config.php та .htaccess, не мають зайвих прав на запис.
• Якщо використовуєте кешування, CDN або плагіни безпеки — спланувати очищення кешу після змін.
• Скласти список для тестування ключових сторінок: адмін-панель, головна сторінка, записи, контакт, сторінки оплати.

Ці приготування займають 10-15 хвилин, але можуть заощадити години простоїв через неправильні налаштування. Для корпоративних сайтів рекомендується робити зміни у години з низьким трафіком.

Блокування PHP у wp-includes через .htaccess на Apache

На спільних хостингах з Apache найпоширеніший спосіб — додати правило у файл .htaccess у корені WordPress. Перед початком роботи обов’язково завантажте копію файлу або зробіть резервну копію через файловий менеджер хостингу.

Рекомендоване правило для .htaccess

Цей метод блокує виклики PHP-файлів у wp-includes, зберігаючи доступ до статичних ресурсів:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

Правило означає: якщо URL починається з wp-includes і закінчується на .php — доступ заборонено. Таким чином PHP-файли не запускаються, а .js, .css, .png, .svg залишаються доступними без проблем. Це оптимальний баланс безпеки і функціональності.

Вимкнення індексації папок

Ще один важливий крок — вимкнути індексацію каталогів, щоб користувачі не бачили вміст папок без індексних файлів. Додайте у ваш основний .htaccess рядок:

Options -Indexes

Ця директива блокує показ списку файлів у папках без index.php або index.html. Більшість сучасних хостингів вимикають індексацію за замовчуванням, але перевірити це варто для безпеки.

Тестування після внесення змін

Після додавання правил виконайте такі перевірки:

• Відкрийте siteadres.com/wp-includes/ — не має відображатися список файлів.
• Спробуйте напряму викликати відомий PHP-файл з wp-includes — має бути 403 або 404.
• Перевірте працездатність головної сторінки, блогу та адмін-панелі.
• Використайте інструменти розробника браузера (Console, Network) для пошуку помилок 403/404.
• Якщо є кеш або CDN — очистіть кеш.

Якщо сайт працює без збоїв і помилок — налаштування можна залишити у продакшені. При помилці 500 швидко поверніть резервну копію .htaccess.

Блокування PHP у wp-includes на Nginx

На серверах з Nginx .htaccess не працює. Правила потрібно додавати у конфігурацію сайту, зазвичай у server block. Для цього потрібен доступ по SSH і права на редагування конфігів. Якщо ви не впевнені, краще звернутися до техпідтримки хостингу.

Приклад правила для Nginx

Базове правило виглядає так:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Це забороняє всі запити до PHP-файлів у папці wp-includes. Після внесення змін перевірте конфігурацію командою:

nginx -t

Якщо тест успішний, застосуйте зміни:

systemctl reload nginx

Reload оновлює конфігурацію без переривання активних з’єднань. На критичних сайтах зміни краще робити у години найменшого навантаження.

Що варто врахувати при роботі з Nginx

• Переконайтеся, що правило додано у правильний server block, особливо якщо на сервері кілька сайтів.
• Якщо використовуєте CDN або реверс-проксі — очищайте кеш CDN перед тестуванням.
• Перевірте, що PHP-FPM обробляє лише потрібні файли.
• Регулярно дивіться логи access.log і error.log для виявлення проблем.

Важливо, щоб правило не конфліктувало з іншими location, що відповідають за обробку WordPress permalink та PHP.

Порівняння методів

У таблиці наведені основні способи обмеження доступу до wp-includes:

Найкращі результати досягаються комбінацією цих методів. Наприклад, на Apache — це .htaccess, правильні права доступу, оновлене ядро, SSL і регулярні резервні копії. Для корпоративних сайтів критично важливий вибір Корпоративний Хостинг із захистом і ізоляцією.

Права доступу та власність файлів

Обмеження доступу до wp-includes без коректних прав доступу буде неповним. Рекомендовані параметри для WordPress — папки 755, файли 644. Це дозволяє серверу читати файли, але обмежує небажані записи. На деяких хостингах можуть бути специфічні налаштування користувачів і груп, тому варто враховувати рекомендації вашої панелі управління.

Особливо небезпечні права 777, які дозволяють запис будь-кому. Це відкриває шлях для завантаження шкідливого коду. Навіть у папках, де дозволений запис, як wp-content/uploads, запуск PHP слід забороняти. Папка wp-includes зазвичай не повинна бути доступною для запису користувача, окрім оновлень WordPress.

Під час аудиту безпеки рекомендується перевірити:

• Папка wp-includes: зазвичай 755
• PHP-файли в wp-includes: 644
• wp-config.php: бажано 600 або більш суворі права
• .htaccess: 644 без зайвих прав на запис

Ці налаштування можуть різнитися залежно від сервера. Неправильні права можуть завадити оновленням або роботі сайту. Після змін рекомендується провести діагностику WordPress та перевірити логи помилок.

Чи виконують це плагіни безпеки?

Плагіни на кшталт Wordfence або iThemes Security можуть автоматично додавати деякі правила для посилення безпеки. Вони корисні для захисту від brute force, моніторингу змін файлів, сканування на шкідливе ПЗ та захисту входу. Однак щодо блокування доступу до wp-includes їхня поведінка може відрізнятися.

Деякі плагіни додають правила у .htaccess, інші — лише на рівні самої програми. Останній варіант захищає після того, як запит уже дійшов до WordPress, тож серверні правила більш ефективні. Тому професійний підхід — поєднувати плагіни з серверними налаштуваннями.

Якщо ви використовуєте плагін безпеки, перевірте:

• Чи додає він правила у .htaccess або конфігурацію Nginx.
• Чи немає конфліктів між правилами плагіна і вашими власними.
• Чи не змінюються налаштування після оновлення плагіна.
• Вплив на продуктивність і використання кешу.

Використання кількох плагінів безпеки одночасно може призвести до конфліктів, зниження швидкості або помилкових блокувань.

Як протестувати захист wp-includes: покрокова інструкція

Щоб переконатися, що блокування працює коректно, виконайте наступні 7 кроків:

• 1. Відкрийте головну сторінку у приватному вікні і перевірте відсутність візуальних дефектів.
• 2. Перейдіть на сторінку блогу, категорії та сторінку результатів пошуку.
• 3. Увійдіть у адмін-панель, відкрийте блок-редактор і медіатеку.
• 4. Перевірте консоль браузера на наявність помилок.
• 5. Вкладка Network має показати завантаження статичних файлів з wp-includes без заборон.
• 6. Спробуйте напряму звернутися до PHP-файла у wp-includes — очікується відповідь 403 або 404.
• 7. Перегляньте логи сервера на предмет нових або повторюваних помилок.

Цей тест займе близько 5 хвилин і допоможе швидко виявити проблеми. Для сайтів з оплатою, як WooCommerce, додатково перевірте кошик, сторінки оплати та обліковий запис користувача. Навіть невелика помилка у JavaScript може вплинути на конверсію.

Додаткові заходи безпеки для структури WordPress

Захист wp-includes — це лише початок. Інші кроки для зниження ризиків включають:

• Не приховуйте версію WordPress, а регулярно оновлюйте ядро.
• Видаляйте непотрібні теми і плагіни повністю.
• Змінюйте ім’я адміністратора на складне і нестандартне.
• Впровадьте двофакторну аутентифікацію.
• Якщо не користуєтеся XML-RPC — обмежте доступ до нього.
• Встановіть ліміти на спроби входу (rate limit) для wp-login.php.
• Регулярно робіть автоматичні резервні копії та перевіряйте їх відновлення.
• Використовуйте HTTPS на всьому сайті; без SSL дані користувачів уразливі.

SSL не блокує доступ до wp-includes, але є базовим рівнем захисту для сесій, форм та адмін-панелі. У багатьох гайдах безпеки SSL вважається першою лінією оборони. Тут доречно додати посилання на придбати сертифікат SSL та Встановлення безкоштовного SSL.

Коли варто звертатися до професіоналів?

Додавання правила в .htaccess на простому Apache-хостингу — досить проста задача. Але якщо у вас Nginx з нестандартною конфігурацією, мультисайт WordPress, магазин WooCommerce, новинний портал з високим трафіком або корпоративний сайт — варто залучити фахівців. Безпека має бути не тільки технічно правильною, але й безпечною для бізнес-процесів.

Рекомендується звернутися за допомогою у таких випадках:

• Якщо хостинг містить кілька WordPress-сайтів.
• Використовуєте Nginx, Varnish, CDN та WAF разом.
• Після останніх змін зросла кількість помилок 403, 404 або 500.
• Сайт раніше був заражений шкідливим ПЗ.
• Опрацьовуєте платежі, обробляєте персональні дані користувачів.

Надійний хостинг, ізоляція, регулярні резервні копії та кваліфікована підтримка — це невидимі, але критично важливі складові безпеки WordPress. Обираючи хостинг, дивіться не лише на дисковий простір, а й на якість підтримки, рівень безпеки, підтримку PHP-версій і SSL. В цьому контексті корисними будуть матеріали Hostragons пакети хостингу та Перенесення сайту WordPress.

Висновок

Для безпеки структури папок WordPress найкраще не блокувати всю папку wp-includes, а закривати доступ лише до PHP-файлів та вимикати індексацію каталогів. Це просто зробити за допомогою .htaccess для Apache або правил location для Nginx. Але перед будь-якими змінами обов’язково робіть резервні копії та перевіряйте працездатність сайту, адмін-панелі та фронтенду.

Коротко: не блокуйте статичні файли, обмежуйте запуск PHP, вимикайте індексацію, контролюйте права доступу і регулярно оновлюйте WordPress. Для надійної, безпечної і зручної роботи вашого сайту рекомендуємо розглянути хостинг, домен та SSL-рішення від Hostragons і звертатись за підтримкою у разі потреби.

Поширені запитання

Чи безпечно повністю закривати папку wp-includes?

Як правило, це не рекомендується. У папці wp-includes є необхідні для роботи WordPress JavaScript, CSS та статичні файли. Повне блокування може порушити відображення сайту або роботу адмін-панелі. Безпечніше заборонити доступ лише до PHP-файлів.

Що робити, якщо після додавання правила в .htaccess з’явилась помилка 500?

Спочатку видаліть додані рядки або відновіть резервну копію .htaccess. Перевірте коректність синтаксису правил. Якщо помилка не зникає, перегляньте логи помилок хостингу або зверніться до техпідтримки.

Чи працює .htaccess на Nginx-сервері?

Ні. .htaccess підтримується лише в Apache і LiteSpeed. Для Nginx потрібно використовувати правила у конфігурації сервера, зокрема в секції server block, і тестувати їх через команду nginx -t.

Чи повністю забезпечує захист блокування доступу до wp-includes?

Ні. Це важливий, але лише один із рівнів захисту. Потрібно також регулярно оновлювати WordPress, використовувати складні паролі, двофакторну аутентифікацію, SSL, резервні копії, файрволи і належні права доступу.

Якщо я використовую плагін безпеки, чи потрібно додавати власні правила для wp-includes?

Залежить від плагіна. Деякі плагіни додають правила в .htaccess, інші захищають лише на рівні додатку. Щоб уникнути конфліктів, рекомендується поєднувати плагіни з серверними правилами для надійнішого захисту.