XML-RPC в WordPress часто отключают «на всякий случай», но это не всегда безопасно. Через этот интерфейс могут работать внешние приложения, мобильные клиенты, некоторые сервисы публикации и старые интеграции. Если просто закрыть доступ без проверки, можно получить тихую поломку: записи перестанут отправляться, приложение редактора не синхронизируется, а часть автоматизации начнёт падать с ошибками 403 или 405.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его без лишнего риска и чем проверить результат после изменений.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешние клиенты и старые интеграции, XML-RPC обычно не нужен. На практике его оставляют включённым только ради конкретных задач: публикация из мобильного приложения WordPress, удалённые редакторы, некоторые сервисы автопостинга и редкие интеграции со сторонними инструментами. Если ничего из этого у вас нет, интерфейс лучше убрать из публичного доступа.
Причина простая: XML-RPC исторически часто используют для перебора логинов и запросов к system.multicall. Это не означает, что сам по себе он «дыра», но лишняя поверхность атаки на сайте обычно не нужна.
Диагностика: используется ли XML-RPC сейчас
Перед отключением проверьте не только код сайта, но и реальные сценарии. Частая ошибка — смотреть только на плагины и забывать про внешние приложения, которые подключены к сайту по старому API.
Что проверить в первую очередь
- Используете ли вы мобильное приложение WordPress для публикации или редактирования.
- Есть ли сервисы автопостинга, которые отправляют записи через XML-RPC.
- Подключены ли внешние редакторы, которые работают не через REST API, а через XML-RPC.
- Не завязаны ли на него старые интеграции с CRM, планировщиками или скриптами.
Быстрая проверка снаружи — отправить тестовый запрос к xmlrpc.php. Если сервер отвечает, интерфейс открыт. Если вы уже подозреваете злоупотребления, полезно посмотреть логи веб-сервера: там часто видно массовые обращения к /xmlrpc.php.
curl -i https://example.com/xmlrpc.phpСам по себе ответ ещё не говорит, что интерфейс нужен, но показывает, что он доступен извне. Если вы видите запросы в логах и не знаете, кто их делает, сначала разберитесь с источником, а уже потом режьте доступ.
Как отключить XML-RPC: три рабочих подхода
Выбор зависит от того, насколько жёстко вы хотите закрыть доступ и есть ли риск сломать интеграции. Для большинства сайтов достаточно одного из двух вариантов: через код или через серверную конфигурацию. Плагин — удобен, но добавляет ещё один слой логики.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Контроль, минимум зависимостей | Нужно понимать, где хранится код | Если есть доступ к файлам и нужен предсказуемый результат |
| Плагин безопасности | Быстро включить | Лишняя зависимость, иногда избыточные функции | Если администрирует не разработчик |
| Серверная блокировка | Режет запрос раньше WordPress | Нужно править конфиг сервера | Если нужен жёсткий запрет на уровне веб-сервера |
Вариант 1: отключить через код
Это самый прозрачный способ. Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin, чтобы настройка не потерялась при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает XML-RPC на уровне WordPress. Если кто-то попытается обратиться к xmlrpc.php, WordPress не будет обслуживать запрос как обычно.
Если вам нужно не полностью отключить интерфейс, а только убрать опасные методы, это уже более тонкая настройка. Но для большинства сайтов проще и надёжнее закрыть XML-RPC целиком.
Вариант 2: заблокировать на уровне сервера
Если сайт работает на Apache, можно закрыть доступ к файлу xmlrpc.php через .htaccess. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>На Nginx блокировка обычно делается в конфигурации сайта. Конкретный блок зависит от вашей схемы, но смысл один: вернуть 403 на запросы к /xmlrpc.php. Это лучше делать аккуратно, чтобы не задеть другие правила.
Серверный способ хорош тем, что снижает нагрузку и не даёт WordPress вообще обрабатывать запрос. Но если конфигом управляет хостинг и вы не уверены в синтаксисе, безопаснее начать с фильтра xmlrpc_enabled.
Вариант 3: использовать плагин
Плагин уместен, если сайт ведёт не разработчик и нужно быстро включать или выключать защиту из админки. Но здесь важно не ставить тяжёлый комбайн ради одной функции. Если у вас уже есть плагин безопасности, проверьте, умеет ли он отключать XML-RPC без побочных эффектов.
Если вы используете набор инструментов для технической чистки сайта, например Clearfy Pro, проверьте, не дублирует ли он уже существующие меры. Лишние плагины безопасности часто создают путаницу: один закрывает доступ, второй пытается его «исправить», и потом сложно понять, кто именно ломает запросы.
Пошаговое решение без сюрпризов
Ниже — практичный порядок действий, который помогает не сломать внешние сервисы и не гадать после внедрения.
- Составьте список всех внешних приложений и сервисов, которые могут обращаться к сайту.
- Проверьте, есть ли среди них те, что используют XML-RPC.
- Сделайте резервную копию файлов и базы перед изменениями.
- Отключите XML-RPC через код или сервер.
- Проверьте доступ к
/xmlrpc.phpи тестовые сценарии публикации. - Посмотрите логи на предмет ошибок 403, 405 и повторных попыток подключения.
Если вы не уверены, начните с временного отключения на тестовой копии сайта. Это особенно полезно, если на продакшене есть старые интеграции, о которых помнят не все.
Как проверить, что решение сработало
Проверка должна быть не только «страница открывается или нет». Нужны два уровня: внешний доступ и рабочие сценарии.
Проверка доступа к XML-RPC
После отключения запрос к xmlrpc.php должен возвращать отказ в доступе или не должен обрабатываться WordPress как раньше. В зависимости от способа блокировки это может быть 403, 404 или другой отказ на уровне сервера.
curl -i https://example.com/xmlrpc.phpЕсли вы отключали через фильтр, а ответ всё ещё обычный, значит код не подхватился: проверьте, где именно он размещён, и не переопределяет ли его другой плагин или тема.
Проверка интеграций
После блокировки попробуйте выполнить реальные действия, которые могли зависеть от XML-RPC:
- отправить черновик из внешнего редактора;
- опубликовать запись из мобильного приложения;
- запустить автопостинг, если он у вас есть;
- проверить API-скрипты, которые обращались к старому интерфейсу.
Если что-то перестало работать, не возвращайте XML-RPC целиком «на всякий случай». Сначала найдите конкретный сервис и посмотрите, можно ли перевести его на REST API или другой способ интеграции.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про мобильное приложение
Это самая типичная проблема. Пользователь видит, что сайт «вроде защищён», а редактор на телефоне перестаёт синхронизироваться. Решение простое: либо вернуть доступ, либо перевести рабочий процесс на другой инструмент.
Спрятали проблему плагином, но не закрыли доступ на сервере
Если плагин просто отключает обработку внутри WordPress, сам файл xmlrpc.php может оставаться доступным. Для снижения лишней нагрузки и шума в логах лучше закрывать запросы ещё на уровне веб-сервера, если это возможно.
Сломали правила безопасности на хостинге
Иногда администратор добавляет блок в .htaccess, а потом хостинг переписывает конфиг или использует собственные правила. В итоге кажется, что XML-RPC закрыт, но это не так. Проверяйте результат фактическим запросом, а не только по наличию строки в конфиге.
Смешали несколько способов блокировки
Когда XML-RPC отключают одновременно плагином, фильтром и серверным правилом, потом сложно понять, что именно вызывает отказ. Если нужен понятный контроль, оставьте один основной способ и зафиксируйте его в документации проекта.
Что ещё стоит сделать для безопасности
Отключение XML-RPC — полезная мера, но не замена нормальной защите входа и обновлениям. Если на сайте уже есть подозрительная активность, проверьте и другие точки:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, темы и плагинов;
- логи на массовые запросы к
/wp-login.phpи/xmlrpc.php; - наличие лишних админов и старых учётных записей.
Если вам нужен более широкий набор технических настроек, имеет смысл держать в проекте один понятный инструмент для чистки и SEO-настроек, а не несколько плагинов, которые делают одно и то же. Но даже в этом случае проверяйте, какие именно функции включены, чтобы не получить конфликтов.
В сухом остатке логика простая: сначала выясняете, нужен ли XML-RPC вашему сайту, затем отключаете его одним понятным способом и только после этого проверяете реальные сценарии работы. Такой порядок экономит время и избавляет от ситуации, когда защита уже включена, а редакторы и интеграции внезапно перестали публиковать контент.