wpcat.ru wordpress WPCat.ru

Как отключить XML-RPC в WordPress, но оставить REST API и обычный вход

|

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

Когда XML-RPC действительно мешает

На практике XML-RPC нужен не всем. Если вы не используете старые приложения для публикации, удалённые клиенты и сервисы, которые обращаются к /xmlrpc.php, этот механизм чаще создаёт риски, чем пользу. Самый частый сценарий — сайт получает много запросов к XML-RPC, а в логах видны попытки перебора паролей через system.multicall или wp.getUsersBlogs.

Но перед отключением важно понять, что именно вы хотите сохранить:

  • обычный вход в админку через /wp-login.php;
  • работу REST API для Gutenberg, мобильных приложений и внешних интеграций;
  • публикацию через сторонние клиенты, если они реально используются;
  • совместимость с плагинами, которые по старой схеме обращаются к XML-RPC.

Диагностика: что сейчас использует сайт

Сначала проверьте, есть ли обращения к XML-RPC в логах сервера или в статистике безопасности. Если у вас установлен плагин защиты, там обычно видно, какие URL атакуют чаще всего. Отдельно посмотрите, не завязаны ли на XML-RPC внешние сервисы: старые приложения для iOS/Android, автоматические публикации и некоторые инструменты синхронизации.

Быстрая проверка доступности XML-RPC

Откройте https://example.com/xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC server accepts POST requests only. Это не ошибка, а признак того, что endpoint живой. Если вы уже что-то блокировали, здесь может быть 403 или 404 — это тоже полезный сигнал, но его нужно сверить с тем, как именно вы блокировали доступ.

Для более точной проверки можно отправить простой POST-запрос:

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Если XML-RPC работает, ответ будет отличаться от обычной страницы 404. Если доступ закрыт, вы увидите 403, 404 или ответ веб-сервера в зависимости от способа блокировки.

Как отключить XML-RPC без лишних побочных эффектов

Есть три нормальных варианта: через код, через серверную конфигурацию и через плагин безопасности. Для точечного контроля чаще всего удобнее код, потому что он прозрачен и легко откатывается.

СпособПлюсыМинусы
Код в теме или mu-pluginТочечный контроль, легко проверитьНужно не забыть про обновления темы
.htaccess / nginxБлокирует запросы раньше WordPressЗависит от сервера, можно ошибиться в конфиге
Плагин безопасностиБыстро включить без кодаЛишняя зависимость, не всегда понятно, что именно он делает

Вариант 1: отключить XML-RPC через фильтр

Если вам нужно именно отключение, добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так решение не пропадёт после смены темы.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот вариант отключает сам XML-RPC на уровне WordPress. При обращении к /xmlrpc.php WordPress перестанет обрабатывать запросы как рабочие.

Вариант 2: заблокировать только опасные методы

Если вы хотите оставить XML-RPC для конкретного старого клиента, но убрать самые проблемные методы, можно фильтровать список доступных вызовов. Это уже более тонкая настройка, но она оправдана только когда есть реальная зависимость.

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    unset( $methods['pingback.ping'] );
    return $methods;
} );

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

Вариант 3: блокировка на уровне веб-сервера

Если у вас Apache, можно закрыть доступ к xmlrpc.php через .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Для nginx правило обычно добавляют в конфигурацию сайта:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Серверная блокировка полезна тем, что запросы не доходят до PHP. Это снижает нагрузку и убирает лишние обращения ещё до WordPress. Но править конфиг нужно аккуратно: одна ошибка в синтаксисе может затронуть весь сайт.

Пошаговое решение на практике

  1. Проверьте, не используют ли XML-RPC внешние сервисы или старые приложения.
  2. Выберите способ блокировки: код, сервер или плагин.
  3. Если нужен быстрый и безопасный откат, используйте mu-plugin.
  4. После внедрения проверьте ответ /xmlrpc.php и логи сервера.
  5. Убедитесь, что вход в админку и REST API работают как раньше.

Если вы выбираете mu-plugin, создайте файл wp-content/mu-plugins/disable-xmlrpc.php и положите туда:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

mu-plugin удобен тем, что он не зависит от активной темы и не отключится случайно после обновления. Для точечных технических правок это часто лучший вариант.

Как проверить, что решение сработало

Проверка должна быть не только визуальной. Смотрите на ответ endpoint и на реальные сценарии, которые вам важны.

  • Откройте /xmlrpc.php в браузере или через curl.
  • Проверьте, что ответ стал 403, 404 или иным ожидаемым отказом.
  • Убедитесь, что /wp-login.php открывается и вход работает.
  • Если вы используете Gutenberg, проверьте сохранение и загрузку записей.
  • Если есть внешние интеграции, сделайте тестовый запрос после изменения.

Для REST API можно быстро проверить публичный endpoint:

curl -i https://example.com/wp-json/

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

Частые ошибки и как их исправить

Отключили XML-RPC через неправильный файл

Если код добавили в родительскую тему, он может исчезнуть после обновления. Для постоянной настройки используйте дочернюю тему или mu-plugin.

Заблокировали не только XML-RPC, но и REST API

Иногда в конфиге сервера по ошибке режут слишком широкий путь или ставят правило, которое задевает /wp-json/. Проверьте, что блокируется именно /xmlrpc.php, а не весь набор API-эндпоинтов.

Сломали сторонний сервис публикации

Если после отключения перестала работать синхронизация, значит сервис действительно использовал XML-RPC. В этом случае либо оставляйте XML-RPC с ограничением методов, либо переводите интеграцию на REST API, если сервис это поддерживает.

Проверили только в браузере

Браузерный тест не всегда показателен. Некоторые блокировки отдают красивую страницу 403, но endpoint всё ещё доступен для POST-запросов. Проверяйте именно POST через curl или аналогичный инструмент.

Безопасность и производительность: что ещё имеет смысл сделать

Если вы уже чистите поверхность атаки, не ограничивайтесь XML-RPC. Проверьте, не открыты ли лишние публичные endpoint'ы, не торчат ли индексы директорий и не используются ли устаревшие плагины. Для сайтов с регулярными атаками полезно дополнительно ограничить частоту запросов к wp-login.php и включить нормальный мониторинг логов.

Если нужен более широкий технический аудит, в экосистеме WPShop есть Clearfy Pro, который закрывает часть типовых задач по чистке WordPress и удалению дублей: https://wpshop.ru/plugins/clearfy. Но если задача только в XML-RPC, отдельный код или серверное правило обычно проще и прозрачнее.

Главная идея здесь простая: отключайте не «всё ради безопасности», а только то, что реально не используется. Тогда вы не потеряете REST API, не сломаете вход и не будете потом искать причину в случайном месте.

×

Время действовать!

Суперцены на
WordPress!

-20%
на премиум темы

Не упусти шанс ⋙