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

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

Ниже — практический вариант без выдуманных хуков и без «магического» отключения всего подряд. Сначала разберём, как понять, что именно у вас ломается, затем покажу безопасный способ через rest_authentication_errors, а после — как проверить результат и не поймать побочные эффекты.

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

Не каждая установка WordPress нуждается в жёстком ограничении REST API. Но есть типичные сценарии, где это оправдано:

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

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

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

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

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

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

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

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

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

    // Пример: оставить доступ к oEmbed и wp/v2 для конкретных сценариев можно точечно,
    // но по умолчанию закрываем всё для гостей.
    return new WP_Error(
        'rest_forbidden',
        __( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
        array( 'status' => 401 )
    );
} );

Этот вариант простой: если пользователь не вошёл в систему, REST API отвечает ошибкой 401. Для админки и редактора это обычно не проблема, потому что авторизованные пользователи продолжают работать как раньше.

Если вам нужно оставить доступ к отдельным маршрутам, добавьте проверку по $_SERVER['REQUEST_URI'] или по $request->get_route() через более точечный фильтр в собственной логике. Но не делайте общий «разрешить всё, кроме...» без списка исключений — так проще случайно открыть лишнее.

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

Иногда нужно не закрыть API полностью, а просто убрать доступ к данным пользователей и служебным объектам. Тогда лучше не рубить всё на уровне rest_authentication_errors, а ограничивать конкретные маршруты через register_rest_route() в своём коде или отключать лишние эндпоинты по месту. Это уже зависит от того, какой плагин их регистрирует.

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

Сравнение подходов

Как проверить, что решение сработало

После внедрения откройте сайт в режиме инкогнито и проверьте адрес /wp-json/. Для гостя должен возвращаться отказ в доступе или пустой ответ в зависимости от вашей логики. Затем войдите в админку и убедитесь, что:

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

Для быстрой проверки можно использовать curl:

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

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

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

Сломался редактор блоков

Чаще всего это значит, что вы закрыли REST API слишком агрессивно и задели авторизованные запросы. Проверьте условие: авторизованным пользователям доступ должен оставаться. Если проблема появилась после установки кода в тему, перенесите его в mu-plugin и временно отключите, чтобы убедиться, что причина именно в фильтре.

Плагины перестали сохранять настройки

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

Сайт выдаёт 401 на публичных страницах

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

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

Ограничение REST API — не замена нормальной защите сайта. Если цель именно безопасность, дополнительно проверьте:

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

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

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

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

Если у вас:

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

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