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