Как отключить XML-RPC в WordPress и не сломать доступ к сайту

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

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

Когда XML-RPC мешает, а когда его лучше оставить

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

Типичные сценарии, где XML-RPC можно отключать

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

Сценарии, где отключение требует проверки

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

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

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

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

Нормально, если вы видите ответ сервера. Сам по себе этот результат не доказывает использование XML-RPC, но показывает, что точка входа открыта. Дальше проверьте:

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

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

Как отключить XML-RPC без плагина

Если зависимостей нет, самый прямой вариант — заблокировать обработку XML-RPC на уровне WordPress. Для этого достаточно добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin.

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

Этот вариант отключает сам механизм на уровне WordPress. Но если вы хотите ещё и отдать корректный ответ на запросы к файлу xmlrpc.php, можно добавить отдельное правило в .htaccess для Apache или в конфигурацию Nginx.

Apache: блокировка через .htaccess

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

Nginx: блокировка на уровне сервера

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

Если у вас есть доступ только к WordPress-коду, начните с фильтра xmlrpc_enabled. Если есть доступ к серверу, лучше закрыть точку входа и на уровне веб-сервера тоже.

Что делать, если XML-RPC нужен только частично

Иногда отключать его полностью не стоит. Например, если одна старая интеграция ещё работает через XML-RPC, а остальной сайт вы хотите защитить. В таком случае лучше не ломать всё сразу, а ограничить доступ на уровне сервера по IP или перенести интеграцию на REST API, если это возможно.

Если интеграция всё ещё нужна, не пытайтесь «чинить» её через ослабление защиты всего сайта. Лучше локализовать доступ и по возможности перевести сервис на REST API.

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

После внедрения проверьте не только сам файл, но и поведение сайта в реальных сценариях. Это важнее, чем просто увидеть код ответа.

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

Хороший практический тест — оставить мониторинг на 24–48 часов и посмотреть, не обращается ли кто-то к xmlrpc.php после блокировки. Если обращений нет, отключение прошло безболезненно.

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

Отключили XML-RPC, а потом перестал работать Jetpack

Некоторые функции Jetpack используют удалённый обмен с сайтом. Если после блокировки вы видите ошибки подключения, проверьте, действительно ли вам нужен этот плагин в текущем режиме. Иногда достаточно отключить только часть функций, а не ломать весь сайт.

Закрыли файл в .htaccess, но запросы всё равно проходят

Так бывает, если сайт работает на Nginx, а правило добавили в Apache-конфиг, который вообще не используется. Проверьте, какой веб-сервер обслуживает сайт, и применяйте блокировку в правильном месте.

Отключили XML-RPC через код, но атаки продолжаются

Фильтр WordPress не всегда достаточно хорош как единственный барьер. Если бот продолжает стучаться в xmlrpc.php, закрывайте точку входа на уровне сервера или WAF. Иначе лишняя нагрузка всё равно будет доходить до PHP.

Сломали внешнюю интеграцию и не знаете какую

В этом случае смотрите логи доступа и ошибочные запросы. Обычно видно, откуда идёт обращение и какой сервис его инициирует. Без логов вы будете гадать, а не диагностировать.

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

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

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

Если нужен более широкий набор мер по чистке сайта и снижению лишних запросов, можно смотреть в сторону инструментов вроде Clearfy Pro, но только как дополнение к ручной проверке, а не как замену пониманию того, что именно вы отключаете.

Короткий чек-лист перед отключением

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

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