Если сайт на WordPress начал получать лишние запросы, а в логах видно обращения к xmlrpc.php и REST API, сначала стоит понять, что именно вы хотите закрыть: старый XML-RPC, публичные REST-эндпоинты или только часть API для гостей. Это разные задачи, и решаются они по-разному. Полное отключение всего подряд часто ломает мобильные приложения, интеграции и некоторые плагины.
Когда проблема действительно в XML-RPC или REST API
Симптомы обычно довольно приземлённые: растёт число POST-запросов к /xmlrpc.php, появляются попытки брутфорса через system.multicall, а в логах веб-сервера заметны обращения к /wp-json/ со странными параметрами. Иногда сайт не атакуют напрямую, но лишняя активность создаёт нагрузку и мешает нормальной индексации и работе кэша.
Что проверить до изменений
- Есть ли у вас внешние интеграции, которые используют XML-RPC: старые мобильные клиенты, сервисы автопостинга, некоторые синхронизации.
- Использует ли тема или плагины REST API на фронтенде, например для поиска, фильтров, формы обратной связи или редактора блоков.
- Есть ли в логах реальные запросы к
xmlrpc.phpс повторяющимися попытками авторизации. - Не закрыт ли уже XML-RPC на уровне хостинга или WAF, чтобы не дублировать настройку.
Пошаговое решение: отключить XML-RPC и сузить REST API
Для большинства сайтов достаточно отключить XML-RPC полностью и оставить REST API только там, где он нужен. Если у вас нет интеграций, завязанных на XML-RPC, это самый простой и предсказуемый вариант.
Вариант 1. Отключить XML-RPC кодом
Добавьте код в мини-плагин или в functions.php дочерней темы. Для продакшена мини-плагин надёжнее: он не зависит от смены темы.
<?php
/**
* Plugin Name: WPINC XML-RPC Disable
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
add_filter( 'xmlrpc_enabled', '__return_false' );После этого запросы к xmlrpc.php должны перестать проходить через WordPress. Но если сервер продолжает отдавать файл напрямую, лучше дополнительно закрыть его на уровне веб-сервера или WAF.
Вариант 2. Закрыть XML-RPC на уровне Nginx
Если у вас Nginx, можно отдать 403 ещё до загрузки WordPress. Это полезно, когда атаки идут массово и вы хотите сэкономить ресурсы PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache логика похожая, но правила будут другими. Если конфигурацию править нельзя, используйте кодовый вариант и проверьте, не закрывает ли хостинг этот файл сам.
Вариант 3. Ограничить REST API для гостей
Полностью отключать REST API обычно не стоит: он нужен самому WordPress и многим плагинам. Но можно ограничить доступ к части маршрутов для неавторизованных пользователей. Ниже пример, который блокирует гостям доступ к пользовательским данным через REST, но не трогает публичные маршруты.
<?php
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( is_user_logged_in() ) {
return $endpoints;
}
$blocked = array(
'/wp/v2/users',
'/wp/v2/users/(?P<id>[\d]+)',
);
foreach ( $blocked as $route ) {
if ( isset( $endpoints[ $route ] ) ) {
unset( $endpoints[ $route ] );
}
}
return $endpoints;
} );Этот подход не универсален: если у вас есть фронтенд-логика, которая читает данные пользователей через REST, её придётся адаптировать. Но для обычного сайта это хороший компромисс между безопасностью и совместимостью.
Сравнение подходов: код, сервер, плагин
| Подход | Что закрывает | Плюсы | Минусы |
|---|---|---|---|
| Код в WordPress | XML-RPC, отдельные REST-эндпоинты | Быстро внедрить, легко откатить | Не защищает до загрузки PHP |
| Правило на сервере | XML-RPC полностью | Снимает нагрузку раньше WordPress | Нужен доступ к конфигу |
| Плагин безопасности | Часто XML-RPC и REST-ограничения | Удобно для админов без кода | Лишняя зависимость, возможны конфликты |
Если нужен минимальный и контролируемый набор настроек, удобнее держать это в своём маленьком плагине. Если вы уже используете комплексный плагин безопасности, проверьте, не дублируете ли вы его правила вручную.
Как проверить, что всё сработало
Проверка должна быть не «на глаз», а по конкретным запросам. Для XML-RPC достаточно открыть /xmlrpc.php в браузере или выполнить POST-запрос: сервер должен отвечать отказом или пустой страницей, а не рабочим XML-RPC-ответом WordPress.
curl -i https://example.com/xmlrpc.phpДля REST API проверьте публичный маршрут и закрытый маршрут отдельно. Например, /wp-json/wp/v2/posts обычно должен оставаться доступным, а /wp-json/wp/v2/users для гостя — нет, если вы применили ограничение из примера выше.
curl -i https://example.com/wp-json/wp/v2/posts
curl -i https://example.com/wp-json/wp/v2/usersПосле внедрения ещё раз посмотрите логи веб-сервера и логи безопасности. Если количество обращений к XML-RPC не снизилось, значит правило не применяется на том уровне, где вы ожидали.
Частые ошибки и как их исправить
- Отключили REST API полностью. В итоге ломаются блоки, формы, поиск или плагины. Исправление: ограничивайте только конкретные маршруты, а не весь API.
- Закрыли
xmlrpc.phpв WordPress, но не на сервере. Атаки продолжают грузить PHP. Исправление: добавьте правило в Nginx или Apache, если есть доступ. - Сломали внешнюю интеграцию. Часто это автопостинг, мобильное приложение или сервис публикации. Исправление: проверьте список интеграций до отключения и оставьте XML-RPC только если он реально нужен.
- Вставили код в активную тему. После смены темы защита исчезает. Исправление: вынесите код в мини-плагин.
- Не проверили кэш и CDN. Иногда старые ответы продолжают отдаваться из кэша. Исправление: очистите кэш страницы, серверный кэш и CDN после изменений.
Практические советы по безопасности и производительности
Если цель — не просто закрыть лишний вход, а снизить нагрузку, смотрите на цепочку целиком. XML-RPC лучше резать на сервере, REST API — ограничивать точечно, а для админки оставить двухфакторную аутентификацию и нормальные лимиты на попытки входа. Это даёт больше эффекта, чем попытка «выключить всё подозрительное» одним фильтром.
Для сайтов с большим количеством плагинов полезно сначала протестировать изменения на staging-копии. Особенно это касается REST API: некоторые плагины используют его неочевидно, и поломка проявляется не сразу. Если нужен более широкий аудит дублей, мусора и технических настроек, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Главная идея простая: XML-RPC можно отключать жёстко, REST API — только после проверки, какие маршруты реально используются. Тогда защита не превращается в источник новых проблем.