☰
WEB SECURITY / PRACTICE

Як вимкнути редактор файлів у WordPress і посилити безпеку сайту

Як вимкнути редактор файлів у WordPress і посилити безпеку сайту

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

Для бойового сайту редактор файлів краще вимкнути. Зміна виконується одним параметром у wp-config.php і не блокує штатні оновлення WordPress, тем та плагінів. Нижче наведено безпечний спосіб налаштування, перевірки та додаткового обмеження доступу до адмін-панелі.

Чому редактор файлів небезпечний

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

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

Вимкнення редактора не замінює оновлення, резервне копіювання та захист облікових записів. Це окремий захисний шар, який зменшує можливості зловмисника після компрометації wp-admin.

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

Як вимкнути редактор файлів через wp-config.php

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

Відкрийте wp-config.php у кореневому каталозі WordPress. Додайте константу до коментаря «That’s all, stop editing!», але до рядка, який зазвичай завершує налаштування конфігурації.

  • Не додавайте параметр у functions.php: він має бути в wp-config.php.
  • Не створюйте константу кілька разів у різних частинах файлу.
  • Зберігайте файл у кодуванні без зайвих службових символів на початку.
  • Після зміни перевірте, чи сайт і адміністративна панель відкриваються без помилок.
define('DISALLOW_FILE_EDIT', true);

Правильне розташування рядка

Приклад структури може виглядати так:

define('DISALLOW_FILE_EDIT', true);

/* That's all, stop editing! Happy publishing. */

Як перевірити, що налаштування спрацювало

Увійдіть до wp-admin під обліковим записом із адміністративними правами та перевірте розділ, у якому раніше був доступний редактор файлів тем або плагінів. Після коректного налаштування відповідний пункт має зникнути або стати недоступним.

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

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

  • Відкрийте головну сторінку і кілька критичних сторінок сайту.
  • Перевірте, чи працюють форми, платежі та інтеграції.
  • Переконайтеся, що оновлення тестового плагіна або теми не заблоковане.
  • Перевірте журнал помилок сервера, якщо після зміни з’явилися проблеми.

Що зміниться для Elementor і розробників

Elementor не залежить від вбудованого редактора PHP-файлів WordPress для звичайного редагування сторінок. Ви й надалі зможете змінювати структуру сторінок, стилі та доступні налаштування через інтерфейс Elementor, якщо вони дозволені роллю користувача.

Водночас вимкнення редактора не забороняє всіх способів виконання небезпечного коду. Потрібно окремо контролювати права користувачів, сторонні плагіни, вставки JavaScript, користувацький CSS і функції, які дозволяють додавати код у заголовок або тіло сторінки.

Розробникам слід перенести зміни теми та плагінів у контрольований процес: дочірню тему, власний плагін, репозиторій і тестове середовище. Пряме редагування файлів на бойовому сайті ускладнює відстеження змін і може бути перезаписане під час оновлення.

  • Використовуйте дочірню тему для безпечніших змін шаблонів.
  • Не зберігайте довільний код у редакторі сторінок без перевірки його походження.
  • Тестуйте оновлення Elementor та інших плагінів на staging-сайті.
  • Розмежовуйте ролі: редактор контенту не повинен мати адміністративний доступ без потреби.

Як додатково захистити wp-admin

Вимкнення редактора зменшує ризик, але не запобігає входу в адміністративну панель. Якщо wp-admin доступний з усього інтернету, його потрібно захищати на рівні облікових записів, сервера та мережі.

Для внутрішніх або корпоративних проєктів корисно обмежити доступ до адмін-панелі через VPN, захищену мережу або allowlist дозволених IP-адрес. Перед таким обмеженням переконайтеся, що до сайту матимуть доступ усі необхідні адміністратори та служби автоматизації.

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

  • Обмежте кількість адміністраторів.
  • Увімкніть двофакторну автентифікацію для привілейованих облікових записів.
  • Захистіть сторінку входу від перебору паролів на рівні сервера або засобів безпеки.
  • Не використовуйте однакові паролі для WordPress, хостингу, пошти та SSH.
  • Зберігайте журнали входів і регулярно перевіряйте підозрілі сесії.

Типові помилки та важливі обмеження

Найчастіша помилка — додавання константи після коментаря «That’s all, stop editing!». У такому разі параметр може не спрацювати, оскільки WordPress припиняє обробку подальших налаштувань. Інша проблема — випадкове додавання пробілів, лапок або зайвих символів у PHP-код.

Не плутайте DISALLOW_FILE_EDIT із DISALLOW_FILE_MODS. Перша константа вимикає редактор файлів. DISALLOW_FILE_MODS має ширший вплив і може блокувати встановлення та оновлення плагінів і тем, тому її не слід додавати без розуміння наслідків.

Не намагайтеся відновити редактор на бойовому сайті лише для одноразової правки. Тимчасове увімкнення створює зайвий ризик, а внесені зміни можуть залишитися без аудиту. Якщо потрібна термінова правка, використовуйте резервну копію, SFTP або SSH із журналюванням дій.

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

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

Чи перестануть працювати оновлення після вимкнення редактора?

Ні. DISALLOW_FILE_EDIT вимикає саме редагування файлів через адміністративну панель. Штатні оновлення WordPress, тем і плагінів мають продовжити працювати.

Чи можна вимкнути редактор через плагін?

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

Що робити, якщо після зміни сайт перестав відкриватися?

Перевірте синтаксис wp-config.php, відновіть резервну копію та перегляньте журнал помилок сервера. Сам параметр DISALLOW_FILE_EDIT зазвичай не впливає на фронтенд, тому причиною найчастіше є помилка під час редагування файлу.

Чи захищає це налаштування від усіх атак на WordPress?

Ні. Воно лише прибирає один небезпечний інструмент із wp-admin. Потрібні також оновлення, резервні копії, сильні паролі, двофакторна автентифікація, контроль ролей і захист сервера.

Висновок

Додайте define('DISALLOW_FILE_EDIT', true); до wp-config.php перед коментарем «That’s all, stop editing!», перевірте роботу сайту та не використовуйте адміністративний редактор PHP на бойовому середовищі.

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

← Усі матеріали веб-безпеки