Как отключить XML-RPC в WordPress выборочно: оставить нужные методы и закрыть лишние

Полностью рубить xmlrpc.php — не всегда лучший вариант. На живых сайтах через XML-RPC иногда работают мобильные клиенты, внешние сервисы публикации и старые интеграции. Проблема обычно не в самом файле, а в лишних методах, которые открывают поверхность атаки и не нужны в конкретном проекте.

Ниже — рабочий сценарий: сначала понять, кто вообще использует XML-RPC, потом отключить только лишнее и проверить, что нужные сценарии не сломались.

Когда выборочное отключение XML-RPC действительно нужно

Сценарий типичный: сайт не использует Jetpack, мобильное приложение WordPress не подключено, внешняя публикация не нужна, но xmlrpc.php продолжает отвечать. В логах появляются запросы к system.multicall, pingback.ping и другим методам, которые на большинстве сайтов не дают пользы.

Если просто закрыть файл на уровне сервера, можно неожиданно сломать:

• публикацию из сторонних клиентов, которые ходят через XML-RPC;
• подключение старых мобильных приложений WordPress;
• интеграции, которые используют wp.getUsersBlogs или metaWeblog.newPost;
• Jetpack, если он еще завязан на XML-RPC в вашей конфигурации.

Диагностика: что именно использует XML-RPC

Перед изменениями проверьте, есть ли реальные обращения. Самый простой способ — посмотреть access log веб-сервера. Ищите запросы к /xmlrpc.php и повторяющиеся методы в теле POST-запросов. Если доступа к логам нет, можно временно добавить собственное логирование на уровне WordPress.

Быстрая проверка ответа сервера

Откройте https://example.com/xmlrpc.php в браузере. Нормальный ответ WordPress обычно выглядит как сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не значит, что всё безопасно: сам файл может быть доступен, а методы — активны.

Для более точной проверки можно отправить тестовый запрос через curl:

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?>
<methodCall>
  <methodName>system.listMethods</methodName>
  <params></params>
</methodCall>'

Если сервер возвращает список методов, XML-RPC активен. Если вы уже ограничили его на уровне кода, ответ должен быть ошибкой или пустым отказом в зависимости от реализации.

Пошаговое решение: отключить лишние методы, а не всё подряд

Самый безопасный путь — оставить только те методы, которые реально нужны. Для этого используйте фильтр xmlrpc_methods. Он позволяет удалить отдельные методы до того, как WordPress начнет их обрабатывать.

Вариант 1: убрать pingback и multicall

Это частый минимум для обычного сайта. Pingback почти всегда приносит больше спама и мусора, чем пользы, а system.multicall часто используют в brute force-атаках, потому что он позволяет делать много попыток в одном запросе.

<?php
add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    unset($methods['system.multicall']);

    return $methods;
});

Этот код лучше разместить в мини-плагине или в functions.php дочерней темы, если у вас нет отдельного mu-plugin для технических правок.

Вариант 2: оставить только нужные методы для интеграции

Если XML-RPC нужен только для конкретного клиента, можно сделать белый список. Это жестче, но предсказуемее. Например, если вам нужен только доступ к базовым методам публикации, оставьте только их и удалите всё остальное.

<?php
add_filter('xmlrpc_methods', function ($methods) {
    $allowed = [
        'wp.getUsersBlogs',
        'wp.newPost',
        'wp.editPost',
        'wp.getPost',
        'wp.getPosts',
        'wp.deletePost',
        'wp.uploadFile',
        'wp.getCategories',
        'wp.suggestCategories',
        'wp.newCategory',
    ];

    return array_intersect_key($methods, array_flip($allowed));
});

Такой подход стоит применять только после проверки интеграций. Если вы не уверены, сначала протестируйте на staging-копии.

Вариант 3: запретить XML-RPC для всех, кроме отдельных IP

Если XML-RPC нужен только редакции или внешнему сервису с фиксированным адресом, удобнее ограничить доступ на уровне PHP. Это не замена firewall, но хороший дополнительный слой.

<?php
add_filter('xmlrpc_enabled', function () {
    $allowed_ips = ['203.0.113.10', '203.0.113.11'];
    $remote_ip = $_SERVER['REMOTE_ADDR'] ?? '';

    if (in_array($remote_ip, $allowed_ips, true)) {
        return true;
    }

    return false;
});

Минус очевидный: если IP меняется или сервис работает через пул адресов, придется обновлять список. Для внешних SaaS-интеграций это не всегда удобно.

Сравнение подходов

Подход	Что делает	Плюсы	Минусы
Отключить весь xmlrpc.php на сервере	Блокирует файл целиком	Просто и жестко	Ломает любые интеграции через XML-RPC
Фильтр xmlrpc_methods	Удаляет отдельные методы	Гибко, меньше рисков	Нужно понимать, какие методы реально используются
xmlrpc_enabled	Отключает XML-RPC условно	Можно оставить доступ для части клиентов	Требует аккуратной логики и тестов

Проверка результата после внедрения

После изменений проверьте не только факт ответа сервера, но и конкретные сценарии.

• Запрос system.listMethods больше не возвращает полный список, если вы его ограничили.
• Попытка вызвать pingback.ping завершается ошибкой.
• Мобильное приложение или внешний клиент, который вам нужен, продолжает публиковать записи.
• В логах сервера стало меньше обращений к /xmlrpc.php с повторяющимися попытками авторизации.

Для ручной проверки можно отправить тестовый метод, который вы оставили в белом списке, и убедиться, что он отвечает. Если метод удален, сервер должен вернуть ошибку вида unknown method или аналогичную XML-RPC-ошибку.

Частые ошибки и как их исправить

Отключили XML-RPC на уровне сервера, а потом сломали интеграцию

Такое случается, когда сначала правят .htaccess или конфиг nginx, а потом вспоминают про мобильное приложение или Jetpack. Если интеграция нужна, не блокируйте файл целиком. Используйте фильтр xmlrpc_methods или условное отключение.

Удалили не тот метод

Иногда проблема не в pingback.ping, а в методе, который использует конкретный сервис публикации. Если после изменений внешний клиент перестал подключаться, сравните список методов до и после и верните только то, что действительно нужно.

Проверили только браузером

Открыть xmlrpc.php в браузере недостаточно. Браузер показывает только доступность файла, а не работу методов. Проверяйте POST-запросом и, если возможно, через реальный клиент.

Сделали правку в родительской теме

Если код лежит в теме, при обновлении он исчезнет. Для таких изменений лучше использовать mu-plugin или отдельный мини-плагин. Это особенно важно для технических ограничений безопасности.

Безопасность и производительность: что еще имеет смысл сделать

Выборочное отключение XML-RPC хорошо сочетается с другими мерами:

• ограничение частоты запросов на уровне WAF или nginx;
• отключение pingbacks, если они не нужны вообще;
• проверка логов на повторяющиеся попытки авторизации;
• обновление плагинов и ядра WordPress, чтобы не оставлять лишние точки входа.

Если на сайте много технических дублей, мусорных архивов и лишних служебных страниц, имеет смысл дополнительно пройтись по SEO-настройкам и индексации. В таких задачах полезны инструменты вроде Clearfy Pro, если вам нужен практический набор для чистки дублей и технических мелочей, но саму логику XML-RPC лучше все равно держать в коде или на сервере, а не в интерфейсе плагина.

Когда лучше отключить XML-RPC полностью

Полное отключение разумно, если вы точно не используете:

• мобильные приложения WordPress;
• удаленную публикацию через старые клиенты;
• Jetpack или другие сервисы, завязанные на XML-RPC;
• внешние интеграции, которым нужен этот протокол.

Если хотя бы один пункт под вопросом, сначала ограничьте методы, а не рубите доступ целиком. Это дешевле по рискам и проще в откате.