XML-RPC в WordPress часто отключают «на всякий случай», а потом неожиданно перестают работать мобильное приложение, Jetpack или внешняя интеграция. Проблема не в самом отключении, а в том, что перед ним не проверили, кто именно использует этот канал.
Если задача — убрать лишнюю поверхность атаки и при этом не потерять нужные подключения, лучше идти по схеме: сначала диагностика, потом точечное ограничение, и только затем полное отключение.
Когда XML-RPC действительно стоит отключать
XML-RPC нужен для удалённой публикации, некоторых старых интеграций и части сервисов, которые до сих пор обращаются к WordPress не через REST API. Если сайт не использует эти сценарии, держать endpoint открытым смысла мало: он часто попадает в брутфорс-сканирование и может создавать лишнюю нагрузку.
Но отключение «в лоб» не подходит, если у вас:
- подключён Jetpack и он использует XML-RPC для части функций;
- работает мобильное приложение WordPress;
- есть внешняя система публикации или синхронизации контента;
- старый сервис авторизации/пингбэков ещё завязан на XML-RPC.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями проверьте логи веб-сервера. Это самый надёжный способ понять, есть ли реальные обращения к xmlrpc.php и откуда они идут. Если у вас включён доступ к access.log, ищите запросы к этому файлу и частоту обращений.
Что смотреть в логах
Ищите не только сам факт запроса, но и повторяющиеся IP, user-agent и коды ответа. Если видите много POST /xmlrpc.php с одинаковых адресов и не видите легитимных клиентов, это хороший кандидат на отключение.
grep