Як захистити wp-config.php у WordPress: практичні кроки

Чому wp-config.php потрібно захищати в першу чергу

У wp-config.php зазвичай містяться назва бази даних, ім’я користувача, пароль і адреса сервера бази даних. Там же зберігаються AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY та відповідні солі. Ці значення використовуються WordPress для формування й перевірки авторизаційних cookie.

Витік файлу не завжди означає миттєвий повний злам сайту, але ризик дуже високий. Зловмисник може підключитися до бази даних, змінити облікові записи, вставити шкідливий код або використати ключі для підроблення сесій. Саме тому цей файл не можна публікувати у відкритому репозиторії, прикріплювати до заявок у підтримку чи надсилати у звичайних чатах.

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

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

Забороніть редагування PHP-файлів з адмінки

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

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

• Після збереження перевірте, що файл не містить синтаксичних помилок.
• Для змін коду використовуйте контрольоване розгортання, SFTP або SSH із персональними обліковими записами.
• Ця константа не блокує завантаження файлів, встановлення плагінів чи виконання вже наявного шкідливого коду.

define('DISALLOW_FILE_EDIT', true);

Де саме розмістити константу

У типовій конфігурації рядок додають у wp-config.php перед коментарем на кшталт «That's all, stop editing». Не вставляйте його всередину масиву, умови або коментаря. Якщо сайт працює у контейнері чи використовує автоматичне розгортання, переконайтеся, що зміна не буде перезаписана під час наступного деплою.

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

Увімкніть HTTPS для адміністративної частини

Паролі, cookie та дані сесії мають передаватися через захищене з’єднання. Для примусового використання HTTPS у вході та адміністративній частині WordPress застосовують константу FORCE_SSL_ADMIN.

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

• Перевірте, що сайт відкривається через https:// без попереджень сертифіката.
• Переконайтеся, що адреси WordPress і сайту узгоджені з HTTPS.
• Після зміни перевірте вхід, вихід, завантаження медіа та збереження сторінок Elementor.
• Якщо перед сайтом працює CDN або reverse proxy, переконайтеся, що сервер правильно визначає початковий HTTPS-запит.

define('FORCE_SSL_ADMIN', true);

Що перевірити після ввімкнення

Відкрийте сторінку входу в приватному вікні браузера, авторизуйтеся та перейдіть до кількох розділів адмінки. Перевірте, чи не з’явилися помилки mixed content, коли частина ресурсів завантажується через HTTP. Окремо протестуйте редактор Elementor: збереження змін, попередній перегляд і завантаження стилів.

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

Замініть ключі та солі WordPress

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

Заміна цих значень робить недійсними активні cookie авторизації. Після збереження змін усі користувачі, включно з адміністраторами, мають увійти до сайту повторно. Це нормальна й очікувана поведінка, а не ознака несправності WordPress.

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

Коли потрібно повторити заміну

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

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

Налаштуйте права доступу та розташування файлу

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

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

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

chmod 600 wp-config.php

Чи можна винести wp-config.php за межі публічного каталогу

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

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

Захистіть файл на рівні веб-сервера

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

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

• Перевірте правила доступу до конфігураційних файлів і резервних копій.
• Не залишайте у публічному каталозі файли з розширеннями .bak, .old, .zip або копії конфігурації.
• Переконайтеся, що помилки PHP не виводять секрети на сторінку для відвідувачів.
• Обмежте SSH, SFTP і панель хостингу персональними обліковими записами та двофакторною автентифікацією, якщо вона доступна.

Резервні копії та фінальна перевірка

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

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

• Сайт відкривається через HTTPS, а сертифікат дійсний.
• Вхід до адмінки та вихід із неї працюють коректно.
• Вбудований редактор PHP-файлів вимкнений.
• Після заміни ключів усі потрібні користувачі можуть увійти повторно.
• Редагування та збереження сторінок Elementor працюють без помилок.
• Права власника й доступу до wp-config.php відповідають конфігурації сервера.
• Резервна копія створена поза публічним каталогом і доступна для відновлення.
• У журналі веб-сервера немає підозрілих запитів до конфігураційних файлів.