XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам, попыткам брутфорса и странным обращениям к /xmlrpc.php. На обычном сайте этот интерфейс нередко не нужен вообще. Но отключать его вслепую тоже не стоит: некоторые мобильные клиенты, внешние сервисы публикации и старые интеграции до сих пор используют XML-RPC.
Ниже — практический сценарий: как понять, нужен ли вам XML-RPC, как отключить его без лишнего риска и как проверить, что после изменений ничего не отвалилось.
Когда XML-RPC действительно стоит отключить
Если вы не публикуете записи через сторонние клиенты, не используете старые интеграции и не подключали сервисы, которым нужен удалённый доступ к WordPress, XML-RPC обычно только создаёт поверхность атаки. Самый частый симптом — в логах много запросов к /xmlrpc.php, иногда с характерными попытками подбора паролей через метод system.multicall.
Отключение особенно уместно, если:
- сайт управляется через обычную админку WordPress;
- нет приложений или сервисов, которые публикуют записи через XML-RPC;
- в логах видны регулярные обращения к
xmlrpc.phpбез понятной причины; - нужно уменьшить лишний шум в безопасности и нагрузку от бесполезных запросов.
Что может сломаться после отключения
Сломаться могут не «все внешние интеграции», а только те, которые реально используют XML-RPC. Это, например, старые мобильные приложения, удалённая публикация через сторонние клиенты, некоторые сервисы автопостинга и отдельные инструменты синхронизации. Если вы не уверены, сначала проверьте, кто вообще обращается к /xmlrpc.php, а уже потом режьте доступ.
Диагностика: как понять, используется ли XML-RPC сейчас
Начните не с отключения, а с проверки фактов. На живом сайте это экономит время: если интеграция есть, вы увидите её сразу.
Проверка по логам сервера
Если у вас есть доступ к access log, найдите обращения к /xmlrpc.php. В зависимости от конфигурации сервера это можно сделать через SSH или панель хостинга. Пример для Linux-сервера:
grep