Как отключить REST API для гостей в WordPress без поломки админки и плагинов

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

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

Когда REST API лучше ограничить, а не отключать полностью

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

• на сайте есть сканеры, которые активно дергают /wp-json/;
• в логах много запросов к REST API от ботов;
• нужно скрыть список пользователей, записей или метаданные от неавторизованных;
• админка и редактор Gutenberg должны продолжать работать;
• часть плагинов использует REST API для AJAX-запросов.

Если цель — просто убрать лишние запросы и дубли, иногда достаточно точечной настройки, а не глобального запрета. Для SEO и чистки сайта это обычно безопаснее, чем «выключить всё и посмотреть, что будет».

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

Перед изменениями проверьте, какие запросы идут в /wp-json/ и кто их инициирует. Это можно сделать в браузере, в логах сервера или через инструменты разработчика.

Что смотреть в первую очередь

• вкладку Network в DevTools — запросы к /wp-json/ на фронтенде и в админке;
• ошибки в консоли браузера после открытия редактора записей;
• access log веб-сервера — частые обращения к REST API от одних и тех же IP;
• плагины, которые работают через блоки, формы, поиск, фильтры, автосохранение.

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

Пошаговое решение: закрыть 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'] ) : '';

    $allowed_prefixes = array(
        '/wp-json/oembed/1.0/',
        '/wp-json/wp/v2/search',
    );

    foreach ( $allowed_prefixes as $prefix ) {
        if ( strpos( $uri, $prefix ) !== false ) {
            return $result;
        }
    }

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

Этот вариант лучше, чем грубая блокировка по rest_api_init или отключение через remove_action, потому что WordPress и плагины продолжают получать нормальный ответ, а не «тихий» сломанный маршрут.

Если нужно закрыть только часть маршрутов

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

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

    $route = $request->get_route();

    if ( 0 === strpos( $route, '/wp/v2/users' ) ) {
        return new WP_Error( 'rest_forbidden', 'Users endpoint is disabled for guests.', array( 'status' => 403 ) );
    }

    return $result;
}, 10, 3 );

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

Сравнение подходов: плагин, код или серверная блокировка

Если у вас уже стоит плагин для чистки сайта и SEO, например Clearfy Pro, проверьте, не решает ли он часть задачи через готовые настройки. Но даже в этом случае полезно понимать, какой именно маршрут вы закрываете и почему.

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

После внедрения не ограничивайтесь открытием главной страницы. Проверка должна быть по сценариям, которые реально ломаются первыми.

• откройте /wp-json/ в браузере без авторизации — должен быть отказ или ограниченный ответ;
• зайдите в админку и откройте редактор записи — он должен работать без ошибок;
• проверьте сохранение записи и автосохранение;
• посмотрите, не появились ли ошибки в консоли браузера;
• протестируйте формы, поиск, фильтры и другие AJAX-функции на фронтенде;
• если есть мобильное приложение или внешняя интеграция, проверьте их отдельно.

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

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

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

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

Отключили REST API через жесткий редирект

Иногда пытаются отправить все запросы на главную или вернуть 404 на уровне сервера. Это ломает не только внешние запросы, но и внутренние механизмы WordPress. Исправление простое: не блокируйте весь путь /wp-json/ без исключений, используйте фильтр WordPress или точечные правила.

Не оставили исключения для редактора и oEmbed

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

Сломали плагины, которые используют REST API как транспорт

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

Проверяли только в админке

Это типичная ошибка. На фронтенде могут продолжать работать скрытые запросы, а в логах — расти количество 401/403. Проверяйте и публичную часть, и авторизованные сценарии.

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

Если цель — снизить шум и поверхность атаки, не ограничивайтесь REST API. Посмотрите на соседние точки входа: xmlrpc.php, лишние архивы, дубли и публичные служебные страницы. В технически нагруженных проектах лучше убирать проблему по слоям, а не одним «запретить всё».

• делайте изменения в дочерней теме или в небольшом mu-plugin, а не в файле темы;
• сначала тестируйте на staging-копии;
• не используйте код, который зависит от $_SERVER['REQUEST_URI'] без проверки окружения и прокси;
• если нужен только контроль доступа, не отключайте REST API полностью;
• после обновления плагинов повторно проверьте список маршрутов.

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

Короткий чек-лист перед публикацией изменений

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

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