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

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

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

Что именно нужно ограничить

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

Важно различать три сценария:

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

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

Перед изменениями проверьте, какие маршруты доступны без авторизации. Самый простой способ — открыть /wp-json/ в браузере или через curl. Если сервер возвращает JSON со списком маршрутов, значит API открыт публично.

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

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

curl -s https://example.com/wp-json/wp/v2/posts?per_page=1

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

Когда REST API лучше не отключать

Не ограничивайте API, если:

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

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

Самый предсказуемый вариант — фильтровать доступ через rest_authentication_errors. Этот подход не ломает админку для авторизованных пользователей и позволяет вернуть 401/403 для гостей.

Добавьте код в functions.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'] ) : '';

    $allowed_paths = array(
        '/wp-json/wp/v2/blocks',
    );

    foreach ( $allowed_paths as $path ) {
        if ( strpos( $request_uri, $path ) !== false ) {
            return $result;
        }
    }

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

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

Если нужен более мягкий вариант

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

add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( is_user_logged_in() ) {
        return $endpoints;
    }

    unset( $endpoints['/wp/v2/users'] );
    unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );

    return $endpoints;
} );

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

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

Если вы не хотите писать код, можно использовать плагин безопасности, но проверяйте, не блокирует ли он REST API слишком агрессивно. В некоторых конфигурациях это ломает редактор блоков или формы. Если нужен более широкий набор инструментов для чистки сайта и удаления дублей, иногда удобнее посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy.

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

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

1. Откройте /wp-json/ в режиме инкогнито.
2. Проверьте ответ через curl — должен быть 401 или 403, если доступ закрыт.
3. Зайдите в админку и откройте редактор записи.
4. Проверьте отправку форм и работу плагинов, которые используют REST.

Пример проверки статуса:

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

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

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

• Блокируют REST API через functions.php активной темы. При смене темы защита исчезает. Лучше вынести код в мини-плагин.
• Отключают API полностью без исключений. В результате ломается редактор блоков или интеграции форм. Сначала проверьте зависимости.
• Проверяют только главную страницу. REST API может быть доступен даже при закрытом фронтенде. Тестируйте именно /wp-json/ и рабочие маршруты.
• Используют слишком широкий список исключений. Тогда защита становится формальной. Оставляйте только те маршруты, которые реально нужны.
• Путают REST API и XML-RPC. Это разные механизмы. Отключение одного не закрывает другой.

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

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

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

Если вам нужно не только закрыть API, но и убрать лишние технические следы в WordPress, полезно смотреть на сайт как на систему: индексация, дубли, служебные endpoints, публичные метаданные и лишние скрипты. Именно в такой последовательности обычно и находят реальные проблемы, а не в попытке «выключить всё сразу».