Рекомендовані права доступу WordPress: 755, 644 і wp-config.php

Ця стаття — локалізована версія японського оригіналу. Читати японський оригінал

Для файлів WordPress основне правило таке: каталогам — права 755, файлам — 644. Файл wp-config.php, у якому містяться дані для підключення до бази даних, слід зробити доступним для ще вужчого кола. Крім самих цифр, перевіряйте й те, хто є власником файлів і від імені якого користувача працює PHP: так ви уникнете і витоку інформації, і проблеми «оновлення не встановлюються». Рекомендовані значення в цій статті звірено з офіційною сторінкою WordPress «Hardening WordPress» (посилення безпеки WordPress) станом на листопад 2026 року.

Як читати цифри прав доступу

Права доступу задаються для трьох груп — «власник, група, інші» — і виражаються сумою значень: читання (4), запис (2), виконання (1).

Право «виконання» (x) для каталогу — це право заходити всередину каталогу. Якщо зняти x з каталогу, файли в ньому стануть недоступними для читання.

Рекомендовані значення для WordPress

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

Деякі хостингові компанії самі визначають рекомендовані значення (бо спосіб запуску PHP на різних серверах різний). Якщо в посібнику вашого сервера вказано значення, віддайте перевагу їм.

Про власника файлів

В офіційному описі сказано, що файли мають належати вашому власному обліковому запису й бути доступними вам для запису. Лише файли, у які WordPress має писати (uploads, теми — якщо ви користуєтеся редактором тем), слід налаштувати так, щоб власник або група збігалися з користувачем вебсервера (PHP) і він міг у них писати.

Якщо віддати вебсерверному користувачеві все, наприклад командою chown -R www-data:www-data, PHP зможе переписувати будь-які файли. У разі експлуатації вразливості плагіна шкода поширюватиметься легше, тож спершу перевірте поточний стан, а потім ухвалюйте рішення.

Запит «даних для підключення (імені хоста, імені користувача й пароля FTP)» під час оновлення плагінів і ядра здебільшого пов’язаний саме з незбігом власників. WordPress обирає спосіб прямого переписування файлів лише тоді, коли власник файлів, створених PHP, збігається з власником файлів WordPress. Якщо вони різні, WordPress просить оновлювати через FTP. Не розширюйте права до 777, а виправте власника.

Перевірте поточні налаштування

Зайдіть по SSH у каталог WordPress і перевірте значення та власника такими командами. Шлях змініть відповідно до свого середовища.

cd /var/www/html

# Права, власник і група wp-config.php
stat -c '%a %U:%G %n' wp-config.php

# Знайти файли й каталоги, доступні іншим користувачам для запису
find . -perm -o=w ! -type l

# Знайти PHP-файли в uploads (зазвичай їх немає)
find wp-content/uploads -type f -name '*.php'

Користувача, від імені якого PHP виконується під час звернення через вебсервер, з’ясуйте в налаштуваннях сервера (наприклад, параметр user пулу PHP-FPM) або в посібнику хостингу. Він не обов’язково збігається з користувачем, від імені якого ви входите по SSH.

Якщо в uploads є PHP-файл, якого ви не впізнаєте, запідозріть зміну сайту сторонніми: перш ніж видаляти, запишіть дату й вміст файлу.

Масово виправте права доступу

Виконуйте в каталозі WordPress. Перед виконанням зробіть резервну копію.

cd /var/www/html

# Установити для каталогів 755, для файлів 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# Обмежити wp-config.php (приклад для середовища, де PHP працює від імені власника файлу)
chmod 600 wp-config.php

Значення для wp-config.php вибирайте залежно від середовища так.

• PHP працює від імені того самого користувача, що й власник файлу (багато спільних хостингів, окремий PHP-FPM для кожного користувача): 600 або 400
• Власник — ваш обліковий запис, а вебсервер читає файл як група: 640 або 440, а групою призначте групу вебсервера

# Приклад: власник — ви, група — вебсервер (www-data), права 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php

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

Якщо встановити 400 або 440, плагіни, що пишуть у wp-config.php (наприклад, ті, що записують налаштування кешу), не зможуть цього зробити. Дозволяйте запис тимчасово лише на час налаштування таких плагінів.

Закрийте wp-config.php від читання через веб

Якщо PHP працює нормально, то під час звернення до wp-config.php із браузера його вміст не показується. Щоб код не відобразився, якщо PHP зупиниться, закрийте доступ і на боці вебсервера. В Apache 2.4 додайте таке в .htaccess у каталозі, де розміщено WordPress (старі Order Deny,Allow / Deny from all — це синтаксис Apache 2.2).

<Files "wp-config.php">
    Require all denied
</Files>

Докладніше див. «Налаштування заборони доступу до wp-config.php».

Доступ до самого .htaccess уже заборонено стандартним налаштуванням Apache (<Files ".ht*"> у httpd.conf).

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

Не дозволяйте виконувати PHP в uploads

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

В Apache 2.4 створіть wp-content/uploads/.htaccess і запишіть у нього таке.

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

Щоб використовувати Require в .htaccess, на сервері має бути дозволено це через AllowOverride. Якщо не дозволено, виникне помилка 500 або налаштування буде проігноровано. Після запису відкрийте URL неіснуючого PHP-файлу на кшталт https://example.com/wp-content/uploads/test.php і переконайтеся, що повертається 403 (якщо й далі 404, налаштування не діє).

В Nginx помістіть таке в блок server перед location ~ \.php$, який обробляє PHP. Це потрібно, тому що location із регулярними виразами зіставляються зверху вниз і використовується перший, що збігся.

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Після зміни налаштувань перевірте синтаксис командою nginx -t і лише тоді перезавантажте конфігурацію.

До того ж WordPress за замовчуванням не приймає завантаження медіафайлів, окрім дозволених типів (зображення, PDF тощо). Завантажити PHP-файл як медіафайл через адмінку зазвичай неможливо.

На що звернути увагу

• Перш ніж змінювати права доступу, зробіть резервні копії файлів і бази даних.
• Якщо ви змінюєте права через FTP-клієнт, деякі сервери не підтримують масової зміни. Коли файлів багато, швидше й надійніше скористатися командою find по SSH.
• Якщо під час оновлення просять дані для FTP, не розширюйте права, а перевірте власника. Допоможе й стаття «Як виправити помилки прав доступу WordPress».
• Регулярно виконуйте наведені вище команди перевірки (файли, доступні іншим користувачам для запису, і PHP в uploads), щоб рано помітити порушення налаштувань чи сторонні зміни.

Маєте запитання щодо WordPress? Видавець сайту перебуває в Японії й відповідає японською. Написати нам (японською)