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

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

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

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

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

Отключение имеет смысл, если:

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

Что не стоит путать с XML-RPC

XML-RPC — это не REST API. Отключение xmlrpc.php не ломает обычную работу Gutenberg, AJAX в админке и стандартный REST API WordPress. Но если у вас старый плагин синхронизации, мобильный клиент или интеграция «из прошлого», их нужно проверить отдельно.

Диагностика: как понять, нужен ли endpoint

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

Проверить можно так:

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

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

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

Обычно вы увидите ответ сервера, но это ещё не означает, что endpoint нужен. Важен именно факт использования.

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

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

Вариант 1: отключить через код

Самый понятный способ — вернуть false для фильтра xmlrpc_enabled. Лучше размещать такой код не в активной теме, а в небольшом mu-plugin, чтобы правило не пропало после смены темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Если нужен более жёсткий вариант, можно ещё и завершать запросы к xmlrpc.php на раннем этапе:

<?php
add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
    }
} );

Но на практике первого фильтра обычно достаточно. Второй вариант полезен, если вы хотите явно отдавать 403 и не оставлять endpoint в рабочем состоянии даже частично.

Вариант 2: отключить через плагин

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

Плюс плагина — быстрый откат. Минус — ещё одна точка конфигурации, которую легко забыть после обновления или переноса сайта.

Вариант 3: блокировка на сервере

Если вы хотите уменьшить нагрузку до попадания в WordPress, блокируйте xmlrpc.php на уровне nginx или Apache. Это особенно полезно, когда сайт регулярно получает мусорный трафик.

Для nginx можно использовать отдельное правило:

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

Для Apache подойдёт правило в .htaccess:

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

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

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

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

• Откройте /xmlrpc.php в браузере — там не должно быть полезного ответа для атакующего сценария.
• Проверьте POST-запрос через curl или тестовый клиент.
• Убедитесь, что вход в админку работает как обычно.
• Если используется Jetpack, проверьте его статус и связанные функции.
• Посмотрите логи сервера: количество обращений к xmlrpc.php должно либо исчезнуть, либо начать получать 403.

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

curl -X POST https://example.com/xmlrpc.php

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

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

Отключили XML-RPC и сломали интеграцию

Такое бывает, если сайт использует старый мобильный клиент WordPress, Jetpack или внешний сервис публикации. Решение простое: сначала найти источник запросов в логах, потом уже отключать endpoint. Если интеграция нужна, лучше ограничить доступ по IP или закрыть её отдельным правилом, а не рубить всё подряд.

Добавили код в тему и забыли про обновление

Если правило лежит в functions.php, при смене темы оно исчезнет. Для технических ограничений безопаснее использовать mu-plugin: он не отключается из админки и не зависит от дизайна.

Поставили плагин, но endpoint всё равно отвечает

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

Сделали deny all и забыли про кэш или CDN

Если перед сайтом стоит CDN или reverse proxy, убедитесь, что правило применяется на нужном уровне. Иногда запросы продолжают доходить до origin-сервера через промежуточный слой, и в логах это выглядит как будто блокировка не работает.

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

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

• ограничение попыток входа;
• двухфакторную аутентификацию для админов;
• неиспользуемые учётные записи;
• актуальность ядра, темы и плагинов;
• наличие WAF или правил на уровне хостинга.

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

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

• Проверил логи на обращения к xmlrpc.php.
• Убедился, что не нужен Jetpack или старый мобильный клиент.
• Выбрал способ отключения: код, плагин или сервер.
• Сделал бэкап конфигурации.
• Проверил ответ endpoint после изменения.
• Посмотрел, не изменилось ли поведение админки и интеграций.

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