XML-RPC в WordPress часто отключают по одной причине: через него удобно брутфорсить логины и дергать сайт лишними запросами. Но у этого механизма есть и легитимные потребители — мобильное приложение WordPress, старые интеграции, некоторые внешние сервисы публикации. Поэтому правильная задача звучит не «выключить всё подряд», а «понять, нужен ли XML-RPC вообще, и если нет — закрыть его без побочных эффектов».
Ниже — рабочий сценарий: как диагностировать использование XML-RPC, чем его лучше отключать, как проверить результат и какие ошибки чаще всего ломают сайт или создают ложное чувство безопасности.
Когда XML-RPC действительно стоит отключить
Если вы не пользуетесь мобильным приложением WordPress, не публикуете записи через внешние клиенты и не подключали старые сервисы синхронизации, XML-RPC обычно только расширяет поверхность атаки. Сам по себе он не «уязвимость», но на практике часто становится точкой входа для перебора паролей и pingback-атак.
Есть и обратная сторона: если сайт завязан на интеграции, отключение может сломать публикацию, удалённое редактирование или синхронизацию контента. Поэтому сначала проверяем, кто вообще обращается к /xmlrpc.php.
Диагностика: нужен ли вам XML-RPC сейчас
Начните с простых проверок. Они не требуют доступа к серверу и помогают быстро понять, есть ли зависимость от XML-RPC.
Проверка по логам и запросам
Если есть доступ к access log веб-сервера, посмотрите обращения к /xmlrpc.php. Частые POST-запросы от неизвестных IP — типичный признак сканирования или атак. Если же вы видите обращения от знакомых сервисов, сначала разберитесь с ними, а уже потом отключайте endpoint.
На уровне WordPress можно временно поставить плагин для логирования запросов или посмотреть логи безопасности, если они уже есть. Важно не гадать, а увидеть фактические обращения.
Проверка зависимостей
- используете ли вы мобильное приложение WordPress;
- настроена ли публикация через сторонний клиент;
- есть ли интеграции со старым ПО, которое работает через XML-RPC;
- нужны ли pingback/trackback — в большинстве случаев нет;
- не завязан ли на XML-RPC какой-то внутренний скрипт или сервис.
Если хотя бы один пункт вызывает сомнение, не отключайте endpoint вслепую. Сначала проверьте на тестовой копии или в staging.
Как отключить XML-RPC: сравнение подходов
Есть несколько способов закрыть доступ. Они отличаются тем, где именно происходит блокировка: на уровне WordPress, плагина или веб-сервера. Для большинства сайтов достаточно первого или второго варианта.
| Способ | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| Фильтр в теме или мини-плагине | Контроль в коде, без лишних зависимостей | Нужно не забыть о поддержке | Если у вас есть доступ к коду |
| Плагин безопасности | Быстро включается, удобно для админов | Добавляет ещё один слой логики | Если нужен быстрый и понятный интерфейс |
| Блокировка на уровне nginx/Apache | Режет запросы до WordPress | Требует доступа к серверу | Если нужен жёсткий контроль и минимальная нагрузка |
Вариант 1: отключить XML-RPC через код
Самый прозрачный способ — добавить фильтр в мини-плагин или в functions.php дочерней темы. Лучше именно в мини-плагин, чтобы не потерять настройку при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC API. Если у вас нет зависимостей, этого обычно достаточно.
Вариант 2: заблокировать доступ к xmlrpc.php на сервере
Если цель — не просто выключить API, а вообще не отдавать файл наружу, блокируйте запросы на уровне веб-сервера. Это полезно, когда сайт регулярно получает мусорные обращения и вы хотите отсечь их до PHP.
Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика обычно задаётся в конфигурации сервера. Пример:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот способ эффективнее с точки зрения производительности, но требует аккуратности: если у вас есть интеграции, они перестанут работать сразу и без предупреждения.
Вариант 3: использовать плагин безопасности
Если вы не хотите лезть в код и серверную конфигурацию, можно закрыть XML-RPC через плагин безопасности. Удобство здесь в том, что настройка видна в админке и её проще сопровождать. Но проверьте, что плагин действительно блокирует endpoint, а не только скрывает часть функций.
Если вы уже используете Clearfy Pro, у него есть инструменты для технической чистки и отключения ненужных возможностей WordPress. Для таких задач это часто практичнее, чем собирать набор из нескольких мелких плагинов: Clearfy Pro.
Пошаговое решение без лишнего риска
- Проверьте, используется ли XML-RPC на сайте фактически.
- Сделайте резервную копию или протестируйте изменения на staging.
- Выберите способ блокировки: код, сервер или плагин.
- Внедрите изменение только в одном месте, не смешивайте несколько методов сразу.
- Проверьте ответ
/xmlrpc.phpпосле изменения. - Посмотрите логи в течение нескольких дней, чтобы убедиться, что ничего не сломалось.
Если вы работаете с кодом, лучше создать маленький must-use плагин. Так настройка не потеряется при обновлении темы и её легко отключить, если потребуется вернуть XML-RPC.
Как проверить, что отключение сработало
Проверка должна быть не «страница не открывается в браузере», а именно тест endpoint-а. Самый простой способ — отправить запрос к /xmlrpc.php и посмотреть ответ.
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне сервера, часто увидите 403 Forbidden. Если отключали через фильтр WordPress, ответ может отличаться в зависимости от конфигурации, но в любом случае endpoint не должен принимать рабочие XML-RPC-запросы.
Для более точной проверки можно отправить тестовый POST-запрос. Если XML-RPC выключен, WordPress не должен обрабатывать метод как обычно.
curl -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'После внедрения проверьте ещё два места: логи веб-сервера и логи безопасности. Если там продолжают идти запросы, это нормально; важно, чтобы они больше не доходили до WordPress и не создавали лишнюю нагрузку.
Частые ошибки и как их исправить
Отключили XML-RPC, а мобильное приложение перестало работать
Это ожидаемо. Если вам нужен мобильный клиент WordPress, XML-RPC придётся оставить включённым или искать другой способ ограничения доступа, например по IP или через WAF. Не стоит отключать endpoint без понимания, кто им пользуется.
Добавили правило в тему, а потом сменили дизайн
Если код лежит в functions.php активной темы, он исчезнет при смене темы. Для таких задач используйте мини-плагин или mu-plugin. Это надёжнее и проще в сопровождении.
Поставили плагин, но endpoint всё равно отвечает
Не все плагины блокируют запрос на уровне сервера. Некоторые лишь отключают отдельные функции XML-RPC, но сам файл остаётся доступным. Если нужна жёсткая блокировка, проверяйте ответ 403 или закрывайте доступ через nginx/Apache.
Сделали несколько блокировок сразу и не поняли, что именно сработало
Так часто теряется управляемость. Сначала выберите один способ и проверьте его. Если потом нужно усилить защиту, добавляйте второй слой осознанно, а не вслепую.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, отключение — это не только про безопасность, но и про снижение шума в логах и лишних PHP-запросов. Особенно это заметно на сайтах, которые регулярно сканируют боты.
- не храните отключение в активной теме;
- не смешивайте блокировку XML-RPC с другими экспериментами в одном релизе;
- проверяйте, не завязан ли на endpoint внешний сервис публикации;
- если используете WAF или CDN, добавьте правило там же, где уже есть защита от перебора логина;
- после изменений смотрите не только HTTP-код, но и фактические ошибки в логах.
Если вам нужно не только отключить XML-RPC, но и почистить сайт от лишних технических сущностей, имеет смысл смотреть на комплексные инструменты для WordPress, а не собирать десяток точечных плагинов. Но в любом случае сначала проверьте, что именно вы отключаете и как это влияет на реальные сценарии использования сайта.