Как отключить открытые XML-RPC и REST API-запросы в WordPress для неавторизованных пользователей

Если сайт на WordPress регулярно получает лишние запросы к xmlrpc.php и публичным REST-эндпоинтам, это обычно видно не по одному симптомy, а по набору мелких проблем: лишняя нагрузка, шум в логах, подозрительные обращения к /wp-json/, попытки перебора авторизации и странные запросы от ботов. Полностью «закрывать всё» нельзя: админка, редактор блоков и часть интеграций завязаны на REST API. Поэтому задача не в тотальной блокировке, а в аккуратном ограничении доступа для неавторизованных запросов.

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

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

Что ломается чаще всего

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

Диагностика проблемы

Начните с проверки логов веб-сервера и аналитики по запросам. Если в логах много обращений к /xmlrpc.php, /wp-json/ или к отдельным REST-маршрутам, это уже повод посмотреть, кто их делает. Для REST API полезно проверить, не идут ли запросы от вашей темы, конструктора или плагинов кеширования. Если сайт работает без ошибок, а лишние запросы идут только от внешних IP и ботов, ограничение обычно безопасно.

Быстрая проверка с сервера:

grep -E "xmlrpc\.php|/wp-json/" /var/log/nginx/access.log | tail -n 50

Если у вас Apache, путь к логам может отличаться, но логика та же: смотрите частоту запросов, коды ответа и User-Agent. Если видите много 401, 403 или повторяющиеся POST-запросы к XML-RPC, это не нормальная рабочая активность.

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

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

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

Если XML-RPC не нужен вообще, его можно отключить фильтром. Это не ломает REST API и не влияет на обычную работу админки.

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

Код лучше добавить в мини-плагин или в functions.php дочерней темы. Если используете плагин для сниппетов, убедитесь, что он не отключается при смене темы.

Вариант 2: закрыть XML-RPC на уровне Nginx

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

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

Для Apache аналогичный эффект обычно делают через правила в .htaccess, но на практике лучше использовать конфигурацию виртуального хоста, если есть доступ. Так проще контролировать порядок правил и не смешивать их с другими редиректами.

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

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

Пример: блокируем REST API для гостей, но оставляем доступ авторизованным пользователям и не трогаем административные запросы.

<?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 доступен только авторизованным пользователям.' ),
        array( 'status' => 401 )
    );
} );

Этот вариант подходит не всем. Если у вас есть публичный фронтенд, который получает данные через REST API, такой код его сломает. Тогда лучше ограничивать не весь API, а только отдельные маршруты через register_rest_route() или проверку прав в callback-функциях.

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

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

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

После внедрения не ограничивайтесь тем, что сайт «открылся без ошибки». Проверьте несколько точек:

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

Проверить REST API можно простым запросом из браузера или через curl:

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

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

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

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

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

Отключили XML-RPC, а потом перестали работать внешние сервисы

Если сайт синхронизируется с мобильным приложением, Jetpack или сервисом автопостинга, XML-RPC может быть нужен. Перед отключением проверьте зависимости. Если сервис критичен, оставьте XML-RPC включённым и ограничьте доступ по IP или через WAF.

Добавили правило в .htaccess и получили 500 ошибку

Частая причина — неверный синтаксис или конфликт с уже существующими правилами. Для проверки временно уберите новое правило и убедитесь, что сайт снова открывается. После этого добавляйте блок аккуратно, без лишних директив и с резервной копией файла.

Ожидали защиту от всех атак, но нагрузка не изменилась

Ограничение XML-RPC и REST API убирает только часть шума. Если атака идёт через другие точки входа, например через wp-login.php или тяжёлые запросы к поиску, нужен отдельный разбор. Здесь полезны rate limiting, кеширование, защита формы входа и аудит плагинов.

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

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

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

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

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