Веб

Безопасность WordPress: чек-лист из 12 пунктов перед экспертизой

Обновления, аудит плагинов, xmlrpc, запрет редактирования файлов, запрет PHP в uploads, админы, 2FA, бэкапы, WAF и контрольные суммы — с командами и настройками.

21 октября 2026 г. · 11 мин. чтения

Фото: Glenn Carstens-Peters, CC0 · Wikimedia Commons

WordPress — широко распространённая платформа для сайтов, и в Узбекистане на нём работает множество корпоративных сайтов и порталов. Его ядро хорошо поддерживается, но риск на реальном сайте обычно не в ядре: он в устаревших плагинах, оставленных открытыми стандартных функциях, лишних администраторах и непроверенных резервных копиях.

В этой статье мы собрали 12 пунктов, которые нужно проверить перед подачей WordPress-сайта на официальную экспертизу кибербезопасности. Для каждого — почему это важно, как проверить и как исправить. Большинство команд выполняется через WP-CLI.

Почему WordPress требует отдельного внимания

Сканеры экспертизы сразу распознают WordPress и запускают специфичные для него проверки: версии ядра и плагинов, перечисление имён пользователей, xmlrpc.php, readme.html, папку uploads. Эти проверки автоматизированы и быстры, поэтому каждая оставленная открытой стандартная вещь превращается в находку в отчёте.

Реальный взлом, который мы недавно вычищали, начался именно так: с одного необновлённого плагина.

1. Ядро, плагины и темы обновлены

Самый важный пункт. Посмотрите, для каких плагинов есть обновления:

wp core check-update
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available

Обновление:

wp core update && wp core update-db
wp plugin update --all
wp theme update --all

Перед обновлением на production сделайте резервную копию и, если возможно, сначала проверьте на staging-копии. Версия PHP тоже должна быть поддерживаемой и с установленными исправлениями безопасности.

2. Аудит плагинов

Каждый плагин — дополнительный код и дополнительная поверхность атаки. Просмотрите список:

wp plugin list --fields=name,status,version

Удалите неактивные плагины. Файлы деактивированного плагина остаются на сервере, и уязвимость в них всё равно может сработать. Не просто деактивируйте, а удалите полностью: wp plugin delete <имя>.
Замените заброшенные плагины. Если плагин давно не обновлялся или удалён из каталога, найдите ему замену.
Откажитесь от «nulled» (взломанных платных) плагинов. Их часто распространяют с заранее встроенным бэкдором.
Проверьте незнакомые плагины. Плагин со случайным именем может быть признаком взлома.

3. xmlrpc.php закрыт

xmlrpc.php — старый интерфейс удалённого управления. Его часто используют для подбора паролей: в одном запросе можно отправить множество попыток входа. Если нет сервиса, который его использует (например, мобильного приложения или Jetpack), закройте его.

Проверка:

curl -s -X POST https://site.uz/xmlrpc.php \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Если в ответе возвращается список методов, интерфейс открыт. Закрытие в nginx:

location = /xmlrpc.php { deny all; }

В Apache, .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

4. Редактирование файлов из админки отключено

В админ-панели WordPress можно напрямую редактировать файлы тем и плагинов. Если аккаунт администратора захвачен, это мгновенно превращается в выполнение кода на сервере. Добавьте в wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Более строгий вариант — DISALLOW_FILE_MODS: он запрещает из админки ещё и установку и обновление плагинов. В этом случае обновления должны выполняться через WP-CLI или процесс деплоя — иначе сайт перестанет обновляться.

define('DISALLOW_FILE_MODS', true);

5. В папке uploads PHP не выполняется

wp-content/uploads — место, куда пользователи загружают файлы. Если атакующий сможет положить туда PHP-файл, а сервер его выполнит, это полный контроль. Проверка:

find wp-content/uploads -type f -iname '*.php*'

Результат должен быть пустым. Затем запретите выполнение PHP на уровне веб-сервера. nginx:

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

Для Apache — wp-content/uploads/.htaccess:

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

Подробнее о загрузке файлов: уязвимости загрузки файлов.

6. Аккаунты администраторов в порядке

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Знайте, кому принадлежит каждый администратор. Незнакомый аккаунт проверяется немедленно.
Не используйте предсказуемые логины вроде admin.
Сотрудникам, работающим с контентом, достаточно роли editor или author — не администратора.
Удаляйте аккаунты уволившихся сотрудников.

Проверьте и раскрытие имён пользователей — экспертиза отмечает это отдельно:

curl -s https://site.uz/wp-json/wp/v2/users | head -c 300
curl -sI 'https://site.uz/?author=1' | grep -i location

Если логины видны, закройте эндпоинт users для гостей (через functions.php темы или небольшой must-use плагин):

add_filter('rest_endpoints', function ($endpoints) {
    if (!is_user_logged_in()) {
        unset($endpoints['/wp/v2/users']);
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

7. Защита входа и 2FA

Для администраторов должна быть включена двухфакторная аутентификация (2FA) — для этого есть надёжные плагины. Кроме того:

Ограничьте число попыток входа (плагином или rate limiting на уровне веб-сервера).
Требуйте сильные пароли.
По возможности ограничьте доступ к wp-login.php и wp-admin списком IP.

Простой rate limiting для wp-login.php в nginx:

limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Подробнее: защита входа.

8. wp-config.php и права на файлы

wp-config.php не должен читаться другими пользователями: chmod 640 wp-config.php (или 600, если PHP работает от имени владельца файла).
Папки 755, файлы 644 — 777 не должно быть нигде:

find . -type d -perm -o+w
find . -type f -perm -o+w

Режим отладки на production выключен:

define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('FORCE_SSL_ADMIN', true);

Ключи и соли уникальны. При сомнениях — wp config shuffle-salts.

О режиме отладки: debug-режим и раскрытие информации.

9. Версия и лишние файлы скрыты

readme.html, license.txt и <meta name="generator"> на странице раскрывают версию WordPress. Удалите или закройте их:

rm -f readme.html license.txt wp-config-sample.php

remove_action('wp_head', 'wp_generator');

Также проверьте, что в веб-корне не остались файлы и папки вроде .zip, .sql, .bak, .git:

find . -maxdepth 2 \( -name '*.zip' -o -name '*.sql' -o -name '*.bak' -o -name '.git' \)

Открытый архив резервной копии — это весь сайт и база в одном файле.

10. Резервные копии есть, восстановление проверено

Резервное копирование автоматическое и регулярное: файлы и база.
Копия хранится вне сервера — если сайт взломают, резервная копия не должна пострадать.
Архивы резервных копий не в веб-корне. Некоторые плагины бэкапа хранят архивы внутри uploads — проверьте, можно ли до них добраться через браузер.
Восстановление хотя бы раз проверено на практике. Копия, из которой нельзя восстановиться, — не копия.

11. WAF включён

Web Application Firewall останавливает известные шаблоны атак (SQL-инъекции, запросы к эндпоинтам уязвимых плагинов, сканеры) ещё до сайта. Варианты:

На уровне сервера: ModSecurity и OWASP Core Rule Set.
WAF на уровне внешнего прокси или CDN.
Файрвол на уровне плагина WordPress.

WAF не заменяет обновления — это дополнительный слой. Но он полезен в промежутке, когда уязвимость уже опубликована, а исправления ещё нет.

12. Контрольные суммы проверены

Проверьте, что файлы ядра и плагинов совпадают с официальной версией:

wp core verify-checksums
wp plugin verify-checksums --all

Эти команды показывают изменённые или посторонние файлы. Результат должен быть чистым. Если какой-то файл не совпадает — отнеситесь к этому серьёзно и выясните причину. Полезно выполнять эту проверку после каждого обновления и регулярно.

Дополнительно настройте HTTPS и заголовки безопасности: заголовки безопасности: CSP и HSTS.

Короткий чек-лист

Ядро, плагины, темы и PHP — последних версий.
Неактивные, заброшенные и «nulled» плагины удалены.
xmlrpc.php закрыт (если не нужен).
DISALLOW_FILE_EDIT включён.
В uploads нет PHP, и его выполнение запрещено.
Список администраторов проверен, имена пользователей не раскрываются.
Для администраторов включены 2FA и rate limiting входа.
Права на wp-config.php ограничены, отладка выключена, 777 нет.
readme.html, мета-тег generator, архивы и .git в веб-корне удалены.
Резервная копия вне сервера, восстановление проверено.
WAF включён.
wp core verify-checksums и wp plugin verify-checksums --all чисты.

Итог

Подготовка WordPress-сайта к экспертизе — в основном вопрос дисциплины: обновлять, удалять лишнее, закрывать открытые по умолчанию вещи и проверять результат. Эти 12 пунктов не отнимают много времени, но заранее закрывают значительную часть самых частых находок в отчётах экспертизы.

Хотите узнать, насколько ваш WordPress-сайт соответствует этому списку? Оставьте заявку на сканирование — агент Claude AI и наш специалист изучат настройки сайта и сервера, а мы поможем закрыть найденные дыры и подготовиться к экспертизе.