Как отключить XML-RPC в WordPress и защитить сайт от брутфорса

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

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

Когда XML-RPC действительно мешает

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

Типичные признаки, что XML-RPC можно выключать

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

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

Диагностика: как понять, что проблема именно в XML-RPC

Перед изменениями полезно убедиться, что нагрузку или попытки входа действительно вызывает этот endpoint. Самый простой способ — посмотреть access log веб-сервера или журнал в панели хостинга. Ищите строки с xmlrpc.php.

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

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

На большинстве сайтов вы увидите ответ с кодом 200 и текстом о том, что XML-RPC сервер принимает POST-запросы. Это не значит, что он используется, но подтверждает, что endpoint открыт.

Если хотите проверить, не завязан ли сайт на XML-RPC, вспомните конкретные сценарии:

• публикация из стороннего редактора;
• мобильное приложение WordPress;
• Jetpack с удаленными функциями;
• старые интеграции с внешними CMS или скриптами.

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

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

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

Если хотите не просто отключить XML-RPC, а еще и отдать ошибку 403 при прямом обращении к файлу, можно добавить блокировку через init:

<?php
/**
 * Plugin Name: Disable XML-RPC and block access
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
} );

Этот вариант не заменяет серверную блокировку, но помогает закрыть доступ на уровне WordPress, если запрос все же дошел до ядра.

Если нужен более жесткий запрет на сервере

Для Apache можно добавить правило в .htaccess. Для nginx логика будет другой, но смысл тот же: не передавать запрос в WordPress.

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

Важно: перед изменением конфигурации сервера проверьте, что у вас есть доступ к восстановлению настроек. Если сайт обслуживается через managed-хостинг, лучше согласовать блокировку с поддержкой.

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

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

• Откройте https://example.com/xmlrpc.php в браузере — доступ должен быть ограничен или endpoint должен перестать отвечать как рабочий интерфейс.
• Повторите запрос через curl -I и посмотрите код ответа.
• Проверьте логи веб-сервера: новые обращения к xmlrpc.php не должны доходить до WordPress как обычные рабочие запросы.
• Если у вас был Jetpack или внешняя публикация, убедитесь, что они не сломались.

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

curl -X POST https://example.com/xmlrpc.php -d '<methodCall><methodName>system.listMethods</methodName></methodCall>'

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

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

Сайт ломает интеграцию, хотя XML-RPC вроде не нужен

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

Отключили в коде, но endpoint все равно отвечает

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

Поставили плагин безопасности, но атаки не прекратились

Некоторые плагины только ограничивают функциональность внутри WordPress, но не блокируют сам запрос на уровне веб-сервера. Если атака массовая, лучше добавить серверное правило или ограничение через WAF.

Сломали мобильное приложение WordPress

Это ожидаемо: приложение может использовать XML-RPC для части операций. Если оно вам нужно, не отключайте endpoint полностью. В таком случае лучше ограничить доступ по IP, включить дополнительную защиту входа или перейти на другой рабочий сценарий.

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

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

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

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

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