Как отключить XML-RPC в WordPress и защитить REST API от лишних запросов

Если на сайте идут брутфорс-атаки, в логах много запросов к xmlrpc.php, а REST API светит лишние данные, обычно пытаются «закрыть всё сразу». Это плохая идея: часть интеграций, мобильные клиенты и редактор Gutenberg завязаны на REST API, а XML-RPC может быть нужен только в редких сценариях. На практике лучше разделить задачу: отключить XML-RPC, если он не используется, и ограничить REST API точечно, а не рубить его целиком.

Когда это действительно нужно

Сценарий обычно один из трёх:

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

Если сайт использует Jetpack, внешние приложения WordPress, мобильную публикацию или стороннюю синхронизацию через XML-RPC, отключать его без проверки нельзя. С REST API история похожая: Gutenberg, многие темы и плагины используют его штатно.

Диагностика: что именно у вас открыто

Сначала проверьте, есть ли реальное использование. Это проще, чем потом искать, почему перестал работать редактор или интеграция.

Проверка XML-RPC

Достаточно открыть URL /xmlrpc.php. Если ответ не 404, файл доступен. Это ещё не проблема само по себе, но если он не нужен, его лучше закрыть на уровне WordPress и веб-сервера.

Проверка REST API

Откройте /wp-json/ в браузере или через curl. Если сайт отдаёт список маршрутов, REST API работает штатно. Это нормально. Вопрос не в том, чтобы выключить его полностью, а в том, чтобы убрать лишнее: например, скрыть данные пользователей для гостей или запретить доступ к собственным кастомным эндпоинтам без авторизации.

curl -I https://example.com/xmlrpc.php
curl -I https://example.com/wp-json/

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

Что лучше: плагин, код или серверная блокировка

Если задача типовая, я бы начал с кода в mu-plugin: так решение не зависит от темы и не потеряется при обновлении. Серверную блокировку имеет смысл добавлять только после проверки, что сайт не использует XML-RPC.

Пошаговое решение

1. Отключаем XML-RPC

Самый безопасный вариант — запретить сам интерфейс через фильтр. Это не ломает остальной сайт и не трогает REST API.

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

Если нужно именно отрезать доступ на уровне веб-сервера, можно добавить правило в .htaccess для Apache. Но делайте это только если уверены, что XML-RPC нигде не используется.

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

Для Nginx логика делается через location, но конфиг зависит от вашей схемы. Важно не копировать чужой блок без проверки, потому что на разных установках уже могут быть свои правила.

2. Ограничиваем REST API точечно

Полностью отключать REST API на живом сайте обычно не нужно. Лучше запретить доступ гостям к чувствительным маршрутам или скрыть данные пользователей в ответах.

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_forbidden',
            'REST API доступен только авторизованным пользователям.',
            array( 'status' => 401 )
        );
    }

    return $result;
} );

Этот вариант жёсткий: он закроет REST API для всех гостей. Подходит не всем, потому что Gutenberg и публичные блоки на фронтенде могут использовать REST-запросы. Если нужен более мягкий режим, ограничивайте только конкретные маршруты.

add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }

    return $endpoints;
} );

Такой подход полезен, если вы не хотите светить список пользователей. Но не удаляйте маршруты вслепую: сначала проверьте, не использует ли их тема, редактор или плагин.

3. Если нужен mu-plugin, а не правка темы

Для продакшена удобнее положить код в wp-content/mu-plugins/. Тогда он загрузится всегда и не зависит от активной темы.

<?php
/**
 * Plugin Name: Site Security Hardening
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    return $endpoints;
} );

Если вы используете Clearfy Pro, часть задач по отключению лишнего и чистке сайта можно закрыть настройками плагина, но точечные ограничения REST API всё равно удобнее держать в коде, когда нужна предсказуемость поведения.

Чек-лист перед включением ограничений

• проверили, не использует ли сайт Jetpack, мобильные приложения или внешнюю публикацию через XML-RPC;
• сохранили текущий .htaccess или конфиг Nginx перед изменениями;
• проверили, какие REST-маршруты реально нужны теме и плагинам;
• внесли код в mu-plugin или отдельный мини-плагин, а не в functions.php активной темы;
• протестировали вход в админку, редактор записей и публичные страницы.

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

После внедрения проверьте не только код ответа, но и поведение сайта.

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

curl -i https://example.com/xmlrpc.php
curl -i https://example.com/wp-json/wp/v2/users

Если маршрут закрыт корректно, вы увидите отказ в доступе или пустой ответ в зависимости от выбранного метода. Главное — убедиться, что это именно ожидаемое поведение, а не случайная ошибка конфигурации.

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

Отключили REST API целиком и сломали редактор

Это самая частая ошибка. Gutenberg и некоторые плагины используют REST API для автосохранения, загрузки данных и запросов к блокам. Если после ограничения редактор начал сыпать ошибками, откатите жёсткий фильтр и оставьте только точечное скрытие маршрутов.

Добавили правило в .htaccess, но сайт на Nginx

Правило в .htaccess просто не сработает. Для Nginx нужно править серверный конфиг. Если доступа к конфигу нет, используйте фильтр WordPress или плагин безопасности.

Внесли код в functions.php и потеряли его после обновления темы

Для таких задач functions.php — слабое место. Лучше использовать mu-plugin или отдельный плагин. Тогда обновление темы не сотрёт ограничение.

Закрыли XML-RPC, но забыли про внешние интеграции

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

Безопасность и производительность без лишнего риска

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

Если задача шире и вам нужно убрать дубли, мусорные архивы, лишние мета-теги и часть технического шума, удобнее смотреть в сторону комплексной чистки сайта. В таких сценариях полезны инструменты вроде Clearfy Pro, но даже с ними лучше понимать, что именно отключается и зачем.

Практический ориентир простой: сначала выясните, что реально используется, потом отключайте только лишнее. Тогда вы не получите «защиту», которая ломает редактор, API и интеграции одновременно.