XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки: перебор паролей, шум в логах и ненужные запросы к xmlrpc.php. Если вы не используете мобильное приложение WordPress, внешние публикации через старые клиенты или интеграции, которые завязаны именно на XML-RPC, этот интерфейс обычно проще отключить, чем пытаться фильтровать атаки постфактум.
Ниже разберём, как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без поломки админки и что проверить после внедрения. Отдельно покажу вариант с кодом и вариант на уровне сервера — у каждого есть свои ограничения.
Когда XML-RPC действительно мешает
Проблема обычно проявляется не как один явный сбой, а как набор мелких симптомов:
- в логах веб-сервера много запросов к
/xmlrpc.php; - появляются попытки входа с ошибками
403,405или частыеPOSTна этот файл; - нагрузка растёт не от трафика на сайт, а от автоматических проверок и перебора;
- в панели безопасности или WAF видно, что атаки идут именно через XML-RPC.
Если сайт работает только через обычную админку WordPress, REST API и современные плагины, XML-RPC чаще всего не нужен. Но перед отключением стоит проверить зависимости: некоторые старые мобильные приложения, внешние сервисы публикации и отдельные плагины синхронизации могут использовать именно его.
Быстрая диагностика зависимости
Самый практичный способ — посмотреть, есть ли реальные обращения к XML-RPC не только от ботов. Если у вас есть доступ к логам, проверьте User-Agent и IP-адреса. Если видите только массовые попытки перебора, а легитимных клиентов нет, отключение безопасно.
Ещё один простой тест — временно заблокировать xmlrpc.php на staging и проверить:
- работает ли вход в админку;
- не ломается ли публикация из внешних инструментов;
- не падают ли уведомления или интеграции, которые вы реально используете.
Как отключить XML-RPC в WordPress через код
Если нужен управляемый вариант без правок конфигурации сервера, проще всего отключить XML-RPC через фильтр xmlrpc_enabled. Это не ломает ядро и легко откатывается.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы или в небольшой mu-plugin, если вы хотите, чтобы защита не зависела от темы. Для production mu-plugin обычно надёжнее: его сложнее случайно отключить при обновлении темы.
Если нужно не просто отключить, а вернуть понятный ответ
Иногда удобнее явно отдавать 403 на запросы к xmlrpc.php. Это полезно, если вы хотите сократить шум в логах и не оставлять лишнюю точку для перебора.
<?php
add_action( 'init', function () {
if ( isset( $_SERVER['REQUEST_URI'] ) && strpos( $_SERVER['REQUEST_URI'], 'xmlrpc.php' ) !== false ) {
status_header( 403 );
exit;
}
} );Такой подход рабочий, но он уже завязан на PHP-уровень. Если атаки массовые, лучше дополнить его блокировкой на уровне веб-сервера или WAF, чтобы не тратить ресурсы PHP на каждый запрос.
Отключение XML-RPC на уровне сервера
Если у вас есть доступ к конфигурации Nginx или Apache, блокировка на сервере обычно эффективнее: запросы отсекаются раньше, чем WordPress успевает загрузиться.
Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Apache
<Files "xmlrpc.php">
Require all denied
</Files>На shared-хостинге такой доступ есть не всегда, поэтому PHP-фильтр остаётся самым универсальным вариантом. Но если сервер ваш, блокировка на уровне веб-сервера предпочтительнее: она дешевле по ресурсам и понятнее в сопровождении.
Сравнение подходов: код, сервер, плагин
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
Фильтр xmlrpc_enabled | Нужна быстрая и обратимая настройка | Просто внедрить, легко откатить | Запрос всё равно доходит до WordPress |
| Блокировка в Nginx/Apache | Есть доступ к конфигу сервера | Ранний отсев, меньше нагрузки | Нужны права на сервер |
| Плагин безопасности | Нет доступа к коду или серверу | Удобно для админов без разработки | Лишняя зависимость, возможны конфликты |
Если у вас уже стоит плагин безопасности, проверьте, не дублирует ли он эту функцию. Иногда достаточно одной настройки в существующем инструменте, а отдельный код только усложнит поддержку.
Пошаговое решение без лишних рисков
- Проверьте, используете ли вы мобильное приложение WordPress или внешние сервисы, которые работают через XML-RPC.
- Сделайте короткий тест на staging: отключите XML-RPC и проверьте вход, публикацию и интеграции.
- Если зависимостей нет, добавьте
add_filter( 'xmlrpc_enabled', '__return_false' );в mu-plugin или дочернюю тему. - При наличии доступа к серверу добавьте блокировку на уровне Nginx или Apache.
- После внедрения проверьте логи и убедитесь, что запросы к
xmlrpc.phpперестали доходить до WordPress.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере или отправьте тестовый запрос через curl. Если всё отключено корректно, вы не должны получить рабочий ответ XML-RPC.
curl -i https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки:
- при PHP-фильтре WordPress не должен принимать XML-RPC-запросы;
- при серверной блокировке вы увидите
403 Forbiddenили аналогичный ответ; - в логах должно стать меньше попыток перебора через этот файл.
Дополнительно проверьте админку и критичные сценарии: вход, создание записи, работу REST API, отправку форм и интеграции с внешними сервисами. Если что-то сломалось, значит, у вас есть зависимость, которую надо заменить или перенастроить.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли внешнюю публикацию
Это означает, что какой-то сервис действительно использовал XML-RPC. Решение — либо вернуть доступ только для нужного IP, либо перевести интеграцию на REST API, если сервис это поддерживает.
Поставили плагин безопасности и получили конфликт
Некоторые плагины уже блокируют XML-RPC сами. Если вы добавили ещё и свой код, результат может быть неочевидным: один слой блокирует, другой пытается обработать запрос. Оставьте один источник истины — либо плагин, либо код, либо сервер.
Заблокировали не только XML-RPC, но и полезные запросы
Иногда администраторы слишком широко пишут правила в Nginx или .htaccess и случайно задевают другие маршруты. Проверяйте, что правило относится именно к xmlrpc.php, а не ко всему корню сайта.
Считаете, что защита не нужна, потому что сайт маленький
XML-RPC атакуют не по размеру сайта, а по факту наличия уязвимой поверхности. Маленький сайт тоже получает перебор, особенно если у него стандартный логин и слабые пароли.
Что ещё стоит сделать для защиты
Отключение XML-RPC — не замена базовой гигиене безопасности. Если вы уже трогаете этот участок, имеет смысл проверить и соседние настройки:
- включён ли двухфакторный вход для администраторов;
- нет ли слабых паролей у редакторов и авторов;
- ограничены ли попытки входа;
- обновлены ли ядро, темы и плагины;
- не открыт ли REST API шире, чем нужно для вашего проекта.
Если вам нужен более широкий набор технических настроек для чистки и защиты сайта, можно посмотреть и на Clearfy Pro. Но в любом случае сначала проверьте, что именно вам нужно отключить, а что должно остаться рабочим.
Практический ориентир простой: если после отключения XML-RPC сайт продолжает работать как раньше, а в логах стало меньше мусора и попыток перебора, значит, решение выбрано правильно. Если же у вас есть внешняя интеграция, не спешите рубить доступ полностью — лучше ограничить его точечно и задокументировать, зачем он нужен.