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

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

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

Когда отключение действительно уместно

XML-RPC имеет смысл отключать, если на сайте нет:

• публикации через старые внешние клиенты;
• мобильного приложения WordPress, которое работает через XML-RPC;
• интеграций, использующих методы system.multicall, pingback.ping или metaWeblog.*.

REST API лучше не отключать целиком. В современном WordPress он используется редактором блоков, некоторыми темами, формами, плагинами кеширования и фронтенд-компонентами. Обычно задача не в полном запрете, а в том, чтобы:

• закрыть публичный доступ к лишним пользовательским данным;
• убрать индексацию и утечки через маршруты, которые не нужны на фронтенде;
• оставить работающими маршруты, без которых ломается админка или блоки.

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

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

Как быстро проверить XML-RPC

Откройте в браузере /xmlrpc.php. Если файл доступен, это еще не значит, что он нужен, но уже повод проверить логи и настройки безопасности. Для более точной проверки можно сделать POST-запрос к методу, например через curl:

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>'

Если ответ приходит и содержит список методов, endpoint активен.

Как понять, нужен ли REST API

В браузере откройте /wp-json/. Если там есть JSON-ответ, это нормально. Дальше посмотрите, какие маршруты реально используются на сайте. Например, блоки редактора, формы и некоторые темы обращаются к wp/v2, а плагины могут добавлять свои namespace.

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

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

1. Отключаем XML-RPC через фильтр

Самый простой и безопасный вариант — отключить XML-RPC на уровне WordPress. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin.

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

Это отключит обработку XML-RPC в WordPress. Если у вас есть серверные правила или WAF, их тоже стоит проверить, но базовая защита уже появится на уровне CMS.

2. Закрываем доступ к xmlrpc.php на уровне сервера

Если сайт работает на Apache, можно добавить правило в .htaccess. Это не замена фильтру WordPress, а дополнительный слой.

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

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

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

После этого запросы к xmlrpc.php должны получать 403.

3. Ограничиваем REST API для неавторизованных пользователей

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

<?php
add_filter( 'rest_authentication_errors', function ( $result ) {
    if ( ! empty( $result ) ) {
        return $result;
    }

    if ( is_user_logged_in() ) {
        return $result;
    }

    $uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

    // Не трогаем публичные маршруты, если они нужны фронтенду.
    if ( str_contains( $uri, '/wp-json/wp/v2/posts' ) ) {
        return $result;
    }

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

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

4. Скрываем лишние REST-маршруты из ответа

Если задача — не запретить API, а убрать лишнюю информацию, можно фильтровать данные в конкретных маршрутах. Например, для записей скрыть поле author или не отдавать мета-данные, которые не нужны публично. Для этого подходят фильтры уровня register_rest_field и rest_prepare_post, но применять их нужно точечно, а не глобально.

Пример: убираем поле author из публичного ответа для записей.

<?php
add_filter( 'rest_prepare_post', function ( $response, $post, $request ) {
    if ( ! $request instanceof WP_REST_Request ) {
        return $response;
    }

    if ( ! current_user_can( 'edit_posts' ) ) {
        $data = $response->get_data();
        unset( $data['author'] );
        $response->set_data( $data );
    }

    return $response;
}, 10, 3 );

Сравнение подходов

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

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

Проверка должна быть не «страница открылась», а по конкретным признакам.

• Запрос к /xmlrpc.php возвращает 403 или не обрабатывается WordPress.
• Попытка POST к XML-RPC-методу больше не дает валидный ответ.
• Публичный /wp-json/ открывается только в тех пределах, которые вы разрешили.
• В консоли браузера нет ошибок у блоков, форм и темы после ограничения REST API.
• В логах сервера нет повторяющихся попыток доступа к закрытым маршрутам от легитимных пользователей.

Для REST API удобно проверить ответ через curl:

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

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

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

Полностью закрыли REST API и сломали редактор

Это самая частая ошибка. Gutenberg и некоторые плагины используют REST API для получения данных и сохранения контента. Если после ограничения редактор стал выдавать ошибки, значит, вы заблокировали слишком много. Решение: вернуть доступ к базовым маршрутам wp/v2 и ограничивать только приватные или лишние endpoints.

Отключили XML-RPC, но забыли про серверный доступ

Если на уровне WordPress XML-RPC выключен, но сервер продолжает принимать запросы, вы все равно будете видеть шум в логах и лишнюю нагрузку на веб-сервер. Добавьте правило в Apache или Nginx, чтобы отсечь запросы раньше.

Использовали слишком общий фильтр без проверки роли

Если в коде нет проверки is_user_logged_in() или current_user_can(), можно случайно закрыть API для администраторов, редакторов и внешних сервисов. Всегда проверяйте сценарий для гостя и для авторизованного пользователя отдельно.

Не протестировали тему и плагины после изменений

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

Практические советы по безопасности и производительности

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

Если сайт большой и с несколькими интеграциями, держите изменения в отдельном mu-plugin. Так код не потеряется при смене темы и его проще отключить при диагностике.

<?php
/**
 * Plugin Name: Site API Hardening
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

Такой подход удобен еще и тем, что изменения можно быстро перенести между окружениями: staging, production, локальная копия.

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