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

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

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

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

Не каждый сайт должен закрывать REST API полностью. На практике это имеет смысл, если:

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

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

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

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

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

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

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

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

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

<?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_disabled_for_guests',
        __( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
        array( 'status' => 401 )
    );
} );

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

Если нужно оставить только отдельные endpoints

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

<?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/wp/v2/posts' ) !== false ) {
        return $result;
    }

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

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

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

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

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

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

Что должно происходить

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

Для быстрой проверки можно открыть адрес /wp-json/ в приватном окне. Если ограничение работает, вы увидите ошибку доступа, а не полный список маршрутов API.

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

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

Закрыли REST API через .htaccess без исключений

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

Заблокировали API для всех пользователей

Это типичная ошибка, когда в коде не проверяют is_user_logged_in(). В результате перестают работать внутренние запросы редактора и часть AJAX-логики. Для WordPress безопаснее ограничивать только гостей, а не всех подряд.

Не проверили тему и плагины

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

Ожидали, что это заменит защиту сайта

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

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

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

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

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

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

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

• Проверил, есть ли на фронтенде реальные запросы к /wp-json/.
• Добавил ограничение только для гостей, а не для всех пользователей.
• Протестировал главную, запись, архив и страницу с блоками.
• Открыл /wp-json/ в приватном окне и убедился, что доступ закрыт.
• Проверил, не сломались ли формы, поиск и динамические блоки.
• Сохранил код в mu-plugin или дочерней теме, а не в основной теме.

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