Права доступа WordPress: 755, 644 и настройка wp-config.php

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

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

Как читать цифры прав доступа

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

«Выполнение» (x) для каталога — это право входить в него. Если снять x с каталога, файлы внутри нельзя будет прочитать.

Рекомендуемые значения для WordPress

Ставить 777 (запись для всех) не нужно. На общем сервере файлы смогут переписать другие пользователи того же сервера.

Некоторые хостинги задают собственные рекомендуемые значения (потому что PHP запускается на серверах по-разному). Если в руководстве вашего хостинга указаны значения, следуйте им.

Как думать о владельце

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

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

Если при обновлении плагина или ядра запрашиваются «данные для подключения (имя хоста FTP, имя пользователя, пароль)», причина чаще всего в несовпадении владельцев. WordPress выбирает прямую перезапись файлов, только если владелец файлов, созданных PHP, совпадает с владельцем файлов 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? Издатель сайта находится в Японии и отвечает по-японски. Связаться (по-японски)