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

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

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

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

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

Типичные сценарии:

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

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

Перед изменениями проверьте, есть ли реальные зависимости. Это можно сделать без сложных инструментов.

Проверка XML-RPC

Если на сайте есть обращения к /xmlrpc.php, это видно в логах веб-сервера или в WAF. Дополнительно можно проверить ответ напрямую:

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

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

Проверка REST API

Откройте в браузере или через curl публичный endpoint:

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

Сам по себе доступ к /wp-json/ не всегда проблема. Важно понять, какие маршруты доступны анонимно и нужны ли они. Например, блок-редактор, некоторые темы и плагины используют REST API на фронтенде и в админке.

Что лучше: отключить полностью или ограничить

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

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

Пошаговое решение через код

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

1. Отключить XML-RPC

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter('xmlrpc_enabled', '__return_false');

Этот вариант отключает сам механизм XML-RPC на уровне WordPress. Если сервер или WAF уже блокирует /xmlrpc.php, лучше не дублировать правила без необходимости, но для WordPress-фильтра это нормальная и понятная защита.

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

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

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

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

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

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

3. Более мягкий вариант: блокировать только чувствительные маршруты

Если вам нужно закрыть только часть API, можно проверять текущий маршрут и блокировать конкретные эндпоинты. Пример ниже показывает общий принцип:

<?php
add_filter('rest_pre_dispatch', function ($result, $server, $request) {
    if (is_user_logged_in()) {
        return $result;
    }

    $route = $request->get_route();

    if (strpos($route, '/wp/v2/users') === 0) {
        return new WP_Error('rest_forbidden', 'Доступ к этому маршруту запрещён.', array('status' => 403));
    }

    return $result;
}, 10, 3);

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

Если удобнее через плагин безопасности

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

Если вы используете набор инструментов для технической чистки и SEO-оптимизации, вроде Clearfy Pro, там обычно есть полезные переключатели для отключения лишних функций WordPress и сокращения поверхности атаки. Но даже в этом случае не стоит включать всё подряд без теста на staging.

Проверка результата после внедрения

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

• Откройте /xmlrpc.php и убедитесь, что он не отвечает как рабочая точка входа.
• Проверьте /wp-json/ в браузере и в curl.
• Авторизуйтесь в админке и убедитесь, что редактор записей открывается без ошибок.
• Проверьте формы, поиск, AJAX-компоненты и блоки, которые могут использовать REST API.
• Посмотрите логи сервера: количество запросов к XML-RPC должно снизиться или исчезнуть.

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

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

Если последний запрос возвращает 401 или 403 для гостя, а админка при этом работает, ограничение настроено корректно.

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

Сломали блок-редактор

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

Перестали работать сторонние интеграции

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

Плагин безопасности дублирует правила

Иногда WordPress-код, серверные правила и плагин безопасности одновременно пытаются блокировать один и тот же endpoint. Это не всегда критично, но усложняет диагностику. Если что-то не работает, временно оставьте только один уровень защиты и проверьте поведение.

Отключили на боевом сайте без теста

Это самая частая практическая ошибка. Даже если решение выглядит простым, сначала проверьте его на staging-копии. Особенно если на сайте есть кастомная тема, REST-виджеты или внешние сервисы авторизации.

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

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

Для производительности важен ещё один момент: не ставьте тяжёлые плагины безопасности ради одной настройки, если задача решается одной строкой кода или правилом на сервере. Чем меньше лишней логики в WordPress, тем проще сопровождать сайт.

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