Как отключить XML-RPC в WordPress без потери нужных функций

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

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

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

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

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

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

Самый простой способ — посмотреть, есть ли обращения к /xmlrpc.php в логах веб-сервера или в логах безопасности. Если логов нет, проверьте вручную типовые сценарии:

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

Можно быстро проверить доступность endpoint без изменений в коде:

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

Если ответ возвращает 200 или 405, файл доступен. Это не значит, что он активно используется, но значит, что его можно атаковать напрямую. Если вы видите в логах регулярные POST-запросы к этому адресу, отключение уже оправдано.

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

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

Пошаговое решение через код

Вариант 1: полностью отключить XML-RPC

Добавьте код в functions.php дочерней темы или, лучше, в mu-plugin. Так он не пропадёт после обновления темы.

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

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

Вариант 2: оставить XML-RPC включённым, но заблокировать только опасные методы

Иногда полный запрет слишком грубый. Например, если нужен один внешний клиент, но не нужны команды для публикации или pingback. Тогда можно фильтровать список методов:

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    unset( $methods['wp.getUsersBlogs'] );
    return $methods;
} );

Такой подход не делает XML-RPC «безопасным», но уменьшает часть лишней функциональности. Используйте его только если точно знаете, какие методы нужны.

Вариант 3: закрыть доступ на уровне сервера

Если задача — не просто выключить функциональность, а вообще не отдавать xmlrpc.php, можно заблокировать файл на уровне веб-сервера.

Для Nginx:

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

Для Apache в .htaccess:

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

Серверное правило полезно, если на сайт идёт много мусорных запросов и вы хотите отсечь их до запуска PHP. Но перед этим убедитесь, что у вас нет зависимостей, иначе внешние клиенты перестанут работать сразу.

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

Проверка должна быть не только «страница открывается». Нужны три шага:

1. Откройте https://example.com/xmlrpc.php в браузере. При полном отключении вы не должны получить рабочий endpoint для удалённых вызовов.
2. Проверьте логи сервера или security-плагина: запросы к xmlrpc.php должны либо отсутствовать, либо получать отказ.
3. Если вы используете мобильное приложение, внешний редактор или интеграцию, попробуйте выполнить реальное подключение и публикацию тестовой записи.

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

curl -X POST https://example.com/xmlrpc.php -d '<?xml version="1.0"?>'

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

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

• Отключили XML-RPC, а потом перестало работать мобильное приложение. Значит, у вас есть зависимость. Верните доступ и либо оставьте XML-RPC включённым, либо перенесите интеграцию на REST API.
• Добавили код в родительскую тему. После обновления темы настройка исчезнет. Перенесите код в дочернюю тему или mu-plugin.
• Поставили правило в Nginx, но endpoint всё равно доступен. Проверьте, что конфиг загружен, и что запрос не уходит через другой location-блок или reverse proxy.
• Использовали security-плагин, который отключил лишнее. У некоторых плагинов есть неочевидные побочные эффекты. Сверяйте список функций, которые они меняют, а не только название кнопки.

Практические советы по безопасности и производительности

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

• закрыт ли доступ к wp-login.php от брутфорса;
• есть ли ограничение по попыткам входа;
• не торчит ли лишняя информация в REST API и HTML;
• обновлены ли ядро, темы и плагины;
• не включён ли кэш, который маскирует результат проверки.

Если вам нужен более широкий набор мер по чистке сайта и удалению дублей, иногда удобнее собрать это в одном инструменте, чем держать россыпь отдельных плагинов. В экосистеме WPShop для таких задач есть Clearfy Pro: Clearfy Pro. Но даже с плагином всё равно проверяйте, что именно он меняет в конфигурации сайта.

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

Полный запрет не подходит, если сайт живёт на старой интеграции, которую нельзя быстро переписать. В таких случаях лучше:

• ограничить только опасные методы;
• закрыть доступ по IP, если клиент известен;
• перевести интеграцию на REST API, если это возможно;
• задокументировать, кто и зачем использует XML-RPC, чтобы не выключить его случайно при следующем аудите.

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