Как отключить открытый REST API для гостей в WordPress

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

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

Когда это вообще имеет смысл

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

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

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

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

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

Что проверить вручную

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

Если после отключения API что-то ломается, обычно это видно сразу: не сохраняются блоки, не подгружаются данные в виджетах, перестают работать формы или фильтры, которые используют REST вместо admin-ajax.php.

Пошаговое решение: ограничить REST API для гостей

Самый безопасный вариант — не отключать REST API полностью, а запретить доступ неавторизованным пользователям. Для этого можно добавить небольшой код в functions.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 )
    );
} );

Этот вариант блокирует запросы для гостей, но оставляет доступ авторизованным пользователям. Для админки и редактора это обычно достаточно. Если у вас есть публичные endpoint'ы, которые должны работать без входа, такой код нужно доработать и разрешить только нужные маршруты.

Как оставить отдельные публичные маршруты

Иногда нужен доступ к конкретному endpoint'у, например для формы или внешнего сервиса. Тогда лучше фильтровать не весь REST API, а только часть маршрутов. Пример ниже показывает идею: разрешаем доступ к маршрутам с префиксом myplugin/v1, а всё остальное закрываем для гостей.

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) || is_user_logged_in() ) {
        return $result;
    }

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

    if ( strpos( $route, '/wp-json/myplugin/v1/' ) !== false ) {
        return $result;
    }

    return new WP_Error(
        'rest_forbidden',
        __( 'REST API закрыт для гостей.', 'textdomain' ),
        array( 'status' => 401 )
    );
} );

Это не идеальный универсальный шаблон, но для точечной настройки он рабочий. Если нужен более строгий контроль, лучше проверять rest_get_route_for_request() или строить whitelist по маршрутам внутри собственного плагина.

Сравнение подходов: плагин, код, серверный запрет

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

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

После изменений проверьте не только страницу /wp-json/, но и реальные сценарии работы сайта.

• Откройте /wp-json/ в режиме инкогнито — должен быть отказ для гостей.
• Войдите в админку и проверьте, что редактор записей открывается без ошибок.
• Сохраните запись и убедитесь, что блоки не ломаются.
• Проверьте формы, комментарии и виджеты, если они используют REST.
• Посмотрите консоль браузера на предмет 401/403 ошибок.

Если у вас есть мониторинг логов сервера, полезно сравнить количество запросов к /wp-json/ до и после. Но главный критерий — не цифры, а отсутствие поломок в редакторе и на фронтенде.

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

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

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

Забыли про публичные интеграции

Если сайт отдаёт данные во внешнее приложение, настраивает headless-фронтенд или использует публичные endpoint'ы плагинов, их нужно явно разрешить. Иначе интеграция начнёт падать с 401/403, а ошибка проявится не сразу.

Проверяли только главную страницу

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

Сделали правку в родительской теме

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

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

Ограничение REST API — не замена нормальной защите сайта, а один из слоёв. Оно уменьшает лишний внешний шум, но не закрывает уязвимости в плагинах и не спасает от слабых паролей. Поэтому вместе с этим стоит проверить:

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

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

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