Как запретить XML-RPC запросы в WordPress без поломки мобильных приложений

XML-RPC в WordPress часто отключают «на всякий случай», а потом получают побочные эффекты: перестаёт работать приложение WordPress на телефоне, ломаются внешние сервисы публикации или интеграции, которые всё ещё ходят через xmlrpc.php. Если задача не в полном удалении функции, а в снижении риска и шума, лучше сначала понять, какие запросы реально нужны, а какие можно отсечь.

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

Когда XML-RPC мешает, а когда его лучше не трогать

XML-RPC нужен не только для старых клиентов. Через него могут работать:

• мобильное приложение WordPress;
• некоторые внешние сервисы автопостинга;
• интеграции с редакторами и CMS-агрегаторами;
• устаревшие плагины, которые не переведены на REST API.

Если вы просто закроете xmlrpc.php на уровне сервера, это может быть безопасно для публичного блога, но проблемно для сайта с интеграциями. Поэтому сначала стоит определить, что именно используется.

Быстрая диагностика проблемы

Проверьте, есть ли обращения к xmlrpc.php в логах веб-сервера. На nginx это обычно access log, на Apache — аналогично. Ищите строки с запросами к /xmlrpc.php и повторяющимися методами вроде system.multicall, pingback.ping или wp.getUsersBlogs.

Если доступа к логам нет, можно проверить ответ вручную:

curl -I https://example.com/xmlrpc.php

Нормальный ответ WordPress — 405 Method Not Allowed на HEAD или POST с телом запроса, но сам факт доступности файла ещё не означает, что он нужен. Важнее понять, используются ли методы XML-RPC в вашей инфраструктуре.

Какой подход выбрать: плагин, код или сервер

Технически есть три варианта. Они не равнозначны.

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

Пошаговое решение: отключить только лишнее

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

Вариант 1. Отключить отдельные XML-RPC методы

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

    return $methods;
} );

Этот вариант полезен, если вам нужно оставить доступ для приложения WordPress или другого клиента, но убрать самые проблемные вызовы. После этого сайт продолжит отвечать на XML-RPC, но часть методов станет недоступна.

Вариант 2. Полностью запретить XML-RPC из WordPress

Если интеграций нет, можно отключить XML-RPC целиком через фильтр xmlrpc_enabled:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Это самый простой способ на уровне WordPress. Он не требует правок сервера и легко откатывается. Но помните: если какой-то внешний сервис всё же использует XML-RPC, он перестанет работать.

Вариант 3. Закрыть доступ к xmlrpc.php на сервере

Если вы уверены, что XML-RPC не нужен вообще, можно заблокировать файл на уровне веб-сервера. Для nginx это выглядит так:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Для Apache обычно используют правило в .htaccess:

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

Этот способ эффективнее с точки зрения нагрузки, потому что запросы не доходят до WordPress. Но он же и самый «жёсткий»: если потом понадобится мобильное приложение или внешняя интеграция, придётся возвращать доступ.

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

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

• Откройте /xmlrpc.php в браузере и убедитесь, что ответ соответствует выбранному способу блокировки.
• Отправьте тестовый POST запрос через curl и проверьте код ответа.
• Посмотрите access log: новые обращения к xmlrpc.php должны либо исчезнуть, либо получать отказ.
• Если на сайте есть мобильное приложение WordPress, попробуйте авторизацию и публикацию черновика.

Пример тестового запроса:

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

Если XML-RPC отключён корректно, вы увидите отказ в доступе или ответ WordPress с ошибкой, в зависимости от выбранного метода блокировки. Главное — убедиться, что поведение совпадает с вашей схемой защиты.

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

Отключили XML-RPC, а потом сломалось приложение WordPress

Значит, у вас был реальный клиент, который ходил через XML-RPC. В этом случае не блокируйте файл на сервере. Вернитесь к варианту с фильтром xmlrpc_methods и отключите только pingback/multicall, либо переведите интеграцию на REST API.

Поставили плагин безопасности, но xmlrpc.php всё ещё отвечает

Некоторые плагины не закрывают файл полностью, а только режут отдельные методы. Это нормально, если так задумано. Проверьте настройки плагина и его документацию: возможно, он защищает только от brute force, а не отключает XML-RPC целиком.

Блокировка на сервере не сработала

Частая причина — правило добавили не в тот контекст. В nginx директива location должна быть в конфигурации сайта, а не внутри произвольного файла. В Apache правило <Files xmlrpc.php> должно применяться в нужной директории и не конфликтовать с другими правилами доступа.

Сайт стал отдавать 403 на всё подряд

Это уже ошибка в синтаксисе или области действия правила. Проверьте, что вы блокируете только /xmlrpc.php, а не весь каталог. Для диагностики временно отключите правило и включайте его снова после точечной проверки.

Что делать с безопасностью и производительностью дальше

Отключение XML-RPC само по себе не закрывает все векторы атак. Если цель — уменьшить шум и риск, полезно дополнительно:

• ограничить частоту запросов к wp-login.php и xmlrpc.php на уровне сервера или WAF;
• убрать ненужные pingback-функции, если они не используются;
• проверить, нет ли старых плагинов, которые продолжают обращаться к XML-RPC;
• следить за логами после изменений, чтобы не пропустить сломанные интеграции.

Если вам нужен более широкий набор технических чисток и отключение лишнего в WordPress, иногда удобнее собрать это в одном наборе настроек, а не держать разрозненные сниппеты. Но даже в этом случае XML-RPC лучше проверять отдельно: у него слишком много внешних зависимостей, чтобы отключать его «вслепую».

Практический критерий простой: если после изменения у вас не осталось легитимных обращений к xmlrpc.php, а мобильные и внешние клиенты работают как раньше, значит, решение выбрано правильно. Если же что-то сломалось — не ищите универсальную кнопку «выключить всё», а возвращайтесь к точечной фильтрации методов.