Как отключить REST API для неавторизованных в WordPress

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

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

Когда REST API действительно стоит ограничить

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

Типичные причины, по которым администраторы идут в эту сторону:

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

Диагностика: что именно открыто сейчас

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

Проверка через браузер и curl

Откройте адрес /wp-json/ и несколько типовых маршрутов:

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

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

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

Если сервер возвращает 200 OK и JSON-ответ доступен без логина, это нормальное поведение для публичных маршрутов. Вопрос в том, нужен ли вам такой доступ. Если нет — ограничиваем его точечно.

Что проверить в админке

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

• блоковый редактор Gutenberg;
• плагины форм с AJAX-отправкой;
• внешняя синхронизация записей;
• мобильные приложения WordPress;
• headless-фронтенд;

то отключать API целиком не стоит. В этом случае лучше ограничить только неавторизованные запросы или отдельные маршруты.

Какой вариант выбрать: плагин, код или частичное ограничение

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

Пошаговое решение: закрываем REST API для гостей

Самый безопасный вариант для большинства сайтов — блокировать REST API только для неавторизованных пользователей, но не трогать запросы из админки и авторизованные сессии. Для этого удобно использовать фильтр rest_authentication_errors.

Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку после обновления темы.

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

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

    // Разрешаем служебные запросы, если они реально нужны.
    $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

    if ( strpos( $request_uri, '/wp-json/' ) === false ) {
        return $result;
    }

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

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

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

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

<?php
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;
    }

    if ( strpos( $route, '/wp-json/' ) !== false ) {
        return new WP_Error(
            'rest_forbidden',
            __( 'Доступ к REST API ограничен.', 'textdomain' ),
            array( 'status' => 401 )
        );
    }

    return $result;
} );

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

Как не сломать редактор и плагины

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

Перед включением ограничения проверьте:

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

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

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

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

• Откройте /wp-json/ в приватном окне браузера — должен быть отказ в доступе или пустой ответ по вашей логике.
• Проверьте /wp-json/wp/v2/posts и /wp-json/wp/v2/users без авторизации.
• Войдите в админку и попробуйте открыть редактор записи.
• Сохраните запись и убедитесь, что нет ошибок в консоли браузера.

Проверка через curl

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

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

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

Блокируют REST API на уровне .htaccess без разбора

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

Пишут проверку только по REQUEST_URI

Такой код может не учитывать прокси, нестандартные маршруты или запросы плагинов. Для точечной защиты лучше опираться на REST-фильтры WordPress, а не на строковый поиск по URL как на единственный критерий.

Не тестируют авторизованные сценарии

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

Оставляют код в активной теме

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

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

Если цель — не просто «спрятать API», а реально снизить риск и шум, смотрите шире:

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

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

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