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

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

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

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

Сначала проверьте, что именно вы хотите защитить. Полное отключение REST API редко оправдано. Чаще всего цель одна из трех:

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

При этом REST API может использоваться:

• редактором Gutenberg;
• некоторыми формами и блоками;
• плагинами кэширования, поиска, аналитики, интеграций;
• внешними приложениями и мобильными клиентами.

Поэтому перед изменениями нужно понять, кто именно обращается к API на вашем сайте.

Диагностика проблемы: что ломается и где смотреть

Проверьте, есть ли реальные обращения к REST API

Откройте сайт в браузере и посмотрите сетевые запросы в DevTools. На вкладке Network отфильтруйте запросы по wp-json. Если на главной, в записях или в админке идут обращения к REST API, значит отключать его полностью нельзя.

Также полезно проверить, не завязаны ли на API плагины, которые вы используете. Типичные признаки:

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

Проверьте, какие маршруты реально нужны

Не все запросы одинаково опасны. Например, публичный маршрут /wp-json/wp/v2/posts может быть нужен для фронтенд-логики, а маршруты ядра и служебные endpoints — для редактора и внутренних механизмов WordPress. Задача — не рубить всё подряд, а ограничить доступ к ненужному.

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

Самый безопасный вариант — не отключать 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;
    }

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

    // Пример: не трогаем запросы, которые явно нужны для фронтенд-логики.
    $allowed_prefixes = array(
        '/wp-json/oembed/1.0',
    );

    foreach ( $allowed_prefixes as $prefix ) {
        if ( str_starts_with( $uri, $prefix ) ) {
            return $result;
        }
    }

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

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

Более аккуратный вариант: блокировать только часть маршрутов

Если вам нужно оставить часть API доступной, лучше фильтровать по маршруту. Например, можно закрыть пользовательские endpoints, но оставить маршруты ядра и oEmbed.

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

    $blocked = array(
        '/my-plugin/v1/private-data',
        '/my-plugin/v1/settings',
    );

    foreach ( $blocked as $route ) {
        if ( isset( $endpoints[ $route ] ) ) {
            unset( $endpoints[ $route ] );
        }
    }

    return $endpoints;
} );

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

Если нужен быстрый вариант через плагин

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

Если вы не уверены в составе сайта, сначала тестируйте на копии. Для REST API это особенно важно: последствия проявляются не сразу, а после сохранения записи, работы формы или обновления блока.

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

После изменений не ограничивайтесь открытием главной страницы. Проверьте несколько сценариев.

• Откройте /wp-json/ в браузере без авторизации.
• Проверьте редактор записей и страниц в админке.
• Сохраните запись с блоками Gutenberg.
• Проверьте формы, AJAX-фильтры и поиск, если они есть.
• Посмотрите консоль браузера на ошибки запросов.

Если вы закрывали API для гостей, ожидаемое поведение зависит от реализации. Варианты:

• для публичного запроса возвращается 401 Unauthorized или 403 Forbidden;
• авторизованный пользователь продолжает получать данные;
• редактор и админка работают без ошибок.

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

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

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

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

Добавили код в тему, а потом сменили шаблон

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

Заблокировали нужный endpoint по пути, а не по смыслу

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

Не проверили кэш и CDN

Иногда старые ответы API остаются в кэше, и кажется, что ограничение не сработало. После внедрения очистите кэш плагина, серверный кэш и CDN, если он есть.

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

• Есть ли на сайте Gutenberg и активные блоки, завязанные на REST API?
• Проверены ли формы, поиск, фильтры и AJAX-виджеты?
• Код вынесен в отдельный плагин или mu-plugin?
• Есть ли staging-копия для теста?
• Проверены ли ответы 401/403 в инкогнито?
• Очищен ли кэш после изменений?

Что делать, если нужен более тонкий контроль

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

• оставить ядро WordPress в покое;
• закрыть только собственные приватные маршруты;
• ограничить доступ по роли или авторизации;
• вести список используемых endpoints в коде проекта.

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

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