Как отключить XML-RPC в WordPress и не сломать нужные интеграции

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

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

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

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

Особенно полезно проверить XML-RPC, если вы видите:

• много запросов к /xmlrpc.php в логах веб-сервера;
• ошибки вида XML-RPC server accepts POST requests only;
• подозрительные попытки system.multicall;
• старые интеграции, о которых уже никто не помнит, но они могут быть критичны.

Что может зависеть от XML-RPC

Чаще всего это:

• старые мобильные приложения WordPress;
• десктопные клиенты для публикации;
• некоторые внешние сервисы автопостинга;
• редкие интеграции с CMS и скриптами, написанными много лет назад.

Если у вас обычный сайт с входом в админку, редактором блоков и без внешней публикации, XML-RPC обычно не нужен.

Диагностика: как понять, используется ли XML-RPC сейчас

Перед отключением проверьте не только код сайта, но и логи. Это быстрее, чем гадать по ощущениям.

Проверка по логам сервера

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

grep