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

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

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

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

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

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

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

Диагностика: как понять, используется ли xmlrpc.php

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

Что проверить перед отключением

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

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

Как отключить XML-RPC: сравнение подходов

Для большинства рабочих сайтов лучший баланс — отключение через код или через сервер с предварительной проверкой зависимостей. Плагин удобен, если сайт ведётся не разработчиком и нужен переключатель в интерфейсе.

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

Если вы хотите отключить XML-RPC на уровне WordPress, добавьте фильтр в functions.php дочерней темы или, что надёжнее, в небольшой mu-plugin. Так решение не потеряется при обновлении темы.

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

Этот вариант отключает сам механизм XML-RPC на уровне WordPress. В большинстве случаев этого достаточно, чтобы запросы к xmlrpc.php перестали обрабатываться штатно.

Если нужен более жёсткий вариант, можно дополнительно вернуть 403 для прямых обращений к файлу на уровне сервера. Для Apache это обычно делают через .htaccess:

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

Для Nginx логика задаётся в конфигурации сайта, а не в .htaccess. Там обычно блокируют доступ к файлу отдельным location-блоком. Конкретный фрагмент зависит от вашей схемы конфигурации, поэтому важно не копировать чужой пример без проверки синтаксиса и порядка правил.

Когда лучше не трогать серверную конфигурацию

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

Как проверить, что отключение сработало

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

Практический чек-лист проверки:

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

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

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

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

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

Поставили плагин безопасности, но запросы всё равно проходят

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

Добавили правило в .htaccess, но ничего не изменилось

Частая причина — сайт работает на Nginx, где .htaccess не используется. Ещё одна причина — правило стоит ниже других директив или файл перезаписывается другим процессом. В таком случае проверяйте именно серверную конфигурацию.

Сломали REST API вместо XML-RPC

Это уже ошибка в правилах блокировки. XML-RPC и REST API — разные механизмы. Если после правок перестали работать мобильные приложения, интеграции или редактор, проверьте, не блокируете ли вы лишние маршруты и не режете ли /wp-json/ по ошибке.

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

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

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

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

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

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

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

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