XML-RPC в WordPress часто отключают «на всякий случай», а потом ловят неожиданные проблемы: перестает работать мобильное приложение, внешняя публикация, старые интеграции или сервисы, которые до сих пор ходят в /xmlrpc.php. Если задача не просто закрыть дыру, а сделать это без побочных эффектов, сначала нужно понять, кто именно использует этот endpoint.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удаленную публикацию, старые приложения и сторонние сервисы синхронизации, XML-RPC чаще всего только создает лишнюю поверхность атаки. Через него обычно пытаются подбирать пароли, проверять доступность сайта или запускать массовые запросы. Но отключение имеет смысл только тогда, когда вы уверены, что ничего важного не сломаете.
Типичный сценарий: сайт управляется из админки, публикации создаются вручную, мобильное приложение WordPress не используется, а интеграции работают через REST API или напрямую через базу/вебхуки. В таком случае XML-RPC можно убрать без потери функциональности.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями проверьте логи сервера и посмотрите, есть ли реальные обращения к xmlrpc.php. Если запросы идут регулярно, это не всегда атака — иногда это внешняя синхронизация, мониторинг или старый плагин.
Что искать в логах
- POST-запросы к
/xmlrpc.php; - частые повторяющиеся IP-адреса;
- ошибки авторизации с одинаковыми именами пользователей;
- запросы от известных сервисов, которые вы подключали раньше.
Если доступа к логам нет, временно можно отследить обращения через серверный access log или через плагин безопасности, но лучше не строить решение только на догадках.
Мини-проверка совместимости
- используете ли вы мобильное приложение WordPress;
- есть ли внешняя публикация через старые клиенты;
- подключены ли сервисы резервного копирования или мониторинга, которые требуют XML-RPC;
- есть ли старые плагины синхронизации контента.
Как отключить XML-RPC безопасно
Самый надежный способ — блокировать endpoint на уровне WordPress или веб-сервера. Если нужен быстрый и обратимый вариант, начните с фильтра в теме или mu-plugin. Это проще откатить, чем править ядро или полагаться только на плагин безопасности.
Вариант 1: отключить XML-RPC через фильтр WordPress
Добавьте код в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам механизм XML-RPC на уровне WordPress. Если кто-то попытается обратиться к xmlrpc.php, запрос не пройдет штатную проверку.
Вариант 2: заблокировать доступ на уровне сервера
Если сайт работает на Apache, можно закрыть файл xmlrpc.php через .htaccess. Это полезно, когда вы хотите отсечь запросы еще до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверный уровень удобен тем, что снижает нагрузку и не дает WordPress даже начать обработку запроса. Но если у вас нет доступа к конфигу, используйте фильтр WordPress.
Вариант 3: точечно ограничить, а не отключать полностью
Иногда XML-RPC нужен только для одного сервиса. В таком случае лучше не выключать все подряд, а сначала понять, можно ли перевести интеграцию на REST API. Если нет — оставьте endpoint включенным, но закройте его на уровне WAF, ограничьте по IP или добавьте дополнительную защиту на стороне сервера.
| Подход | Плюсы | Минусы |
|---|---|---|
Фильтр xmlrpc_enabled | Просто откатить, не зависит от сервера | Запрос все равно доходит до WordPress |
| Apache/Nginx блокировка | Режет трафик раньше, меньше нагрузка | Нужен доступ к конфигу |
| Плагин безопасности | Удобно для админов без доступа к серверу | Лишняя зависимость, не всегда прозрачно работает |
Пошаговое решение без лишнего риска
- Проверьте, используется ли XML-RPC реально, а не «теоретически».
- Сделайте резервную копию конфигурации и файлов, если меняете серверные правила.
- Добавьте блокировку через
xmlrpc_enabledили на уровне веб-сервера. - Очистите кеш сайта и кеш CDN, если он есть.
- Проверьте, не сломались ли мобильное приложение, внешняя публикация и интеграции.
Если вы ведете несколько сайтов, удобнее вынести правило в mu-plugin. Тогда его не забудут после смены темы и не потеряют при обновлениях.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой админки. Нужно убедиться, что endpoint действительно недоступен и что сайт не потерял нужные сценарии.
Проверка через браузер или curl
Откройте https://example.com/xmlrpc.php. В зависимости от способа блокировки вы увидите либо отказ в доступе, либо сообщение WordPress о том, что XML-RPC отключен. Для серверной проверки удобнее использовать curl:
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали доступ на уровне сервера, ожидайте ответ без успешной обработки запроса. Если использовали фильтр WordPress, endpoint может отвечать, но не должен принимать XML-RPC-вызовы.
Проверка побочных эффектов
- попробуйте войти через мобильное приложение WordPress, если оно используется;
- проверьте сторонние сервисы публикации и синхронизации;
- посмотрите, не выросло ли число ошибок в логах после изменения;
- очистите кеш и повторите тест из приватного окна.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать интеграция
Это означает, что сервис все еще зависит от старого механизма. Решение — либо вернуть XML-RPC, либо перевести интеграцию на REST API, если сервис это поддерживает.
Добавили правило в .htaccess, но endpoint все равно отвечает
Частая причина — сайт работает не на Apache, а на Nginx, или правило добавлено не в тот виртуальный хост. Проверьте серверный стек и место, где реально обрабатываются правила.
Поставили плагин безопасности и забыли, что он уже блокирует xmlrpc.php
В итоге сложно понять, какое правило сработало, а при отключении плагина защита исчезает. Лучше держать один понятный способ блокировки и документировать его в проекте.
Отключили XML-RPC, но не закрыли другие точки входа
Это типичная ошибка мышления «закрыли один файл — сайт защищен». На практике нужно еще проверить слабые пароли, лимиты попыток входа, обновления ядра и плагинов, а также доступ к wp-login.php.
Что стоит проверить вместе с XML-RPC
Если вы уже занимаетесь технической чисткой сайта, не ограничивайтесь одним endpoint. В реальных проектах вместе с ним обычно смотрят и другие вещи, которые дают лишнюю нагрузку или создают риски безопасности.
- ограничение попыток входа;
- актуальность ядра, тем и плагинов;
- наличие неиспользуемых плагинов;
- кеширование страниц и объектов;
- логи 404 и подозрительных запросов;
- отключение ненужных REST-маршрутов только если есть понятная причина, а не «на всякий случай».
Если нужен более широкий технический аудит, удобно сначала убрать очевидный шум и дубли, а потом уже трогать точечные ограничения. Для этого часто используют инструменты вроде Clearfy Pro, но сам принцип остается тем же: сначала диагностика, потом изменение, потом проверка по логам и реальному поведению сайта.