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

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

Автор: Евгения Боброва | Опубликовано: 18.10.2026

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

Полное отключение REST API в WordPress почти всегда ломает часть функциональности: редактор Gutenberg, некоторые виджеты, формы, темы и плагины могут обращаться к эндпоинтам API даже на фронтенде. Поэтому безопаснее не рубить API полностью, а поставить проверку доступа и отдавать ответ только авторизованным пользователям.

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

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

Задача здесь простая: разрешить доступ авторизованным пользователям и заблокировать его для тех, кто не вошёл в админку. При этом важно не трогать внутренние запросы WordPress, которые выполняются от имени залогиненного пользователя или в административной части.

Самый надёжный способ: фильтр `rest_authentication_errors`

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

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

Ниже рабочий вариант: REST API будет доступен только авторизованным пользователям. Для гостей WordPress вернёт ответ rest_forbidden с кодом 401.

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

Что делает этот код:

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

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

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

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

Создайте файл, например wp-content/mu-plugins/disable-rest-api-for-guests.php, и вставьте туда код:

<?php
/*
Plugin Name: Disable REST API for Guests
*/

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

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

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

Если папки mu-plugins нет, её можно создать вручную. WordPress подхватывает такие плагины автоматически, отдельная активация в админке не нужна.

Когда этого недостаточно и что делать с фронтендом

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

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

В таких случаях есть три рабочих пути:

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

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

Как проверить, что REST API закрыт только для гостей

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

Что должно получиться:

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

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

Что делать, если на сайте уже есть плагин безопасности

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

Если в плагине есть настройка вида «Disable REST API for guests» или «Restrict REST API», сначала проверьте, есть ли исключения для авторизованных пользователей и админки. Если таких исключений нет, лучше использовать собственный фильтр rest_authentication_errors, потому что он предсказуемее и проще для диагностики.

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

Если нужно, могу помочь адаптировать код под ваш случай: например, оставить доступ только к нескольким маршрутам REST API или проверить, не ломает ли ограничение конкретную тему или плагин.