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

Автор: Маргарита Боброва | Опубликовано: 19.10.2026

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

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

Что делает REST API в WordPress и почему его не стоит рубить без проверки

REST API — это HTTP-интерфейс WordPress, через который можно получать и отправлять данные в формате JSON. Он нужен не только внешним приложениям. Сам WordPress активно использует его внутри админки и на фронтенде.

Если отключить REST API полностью, вы можете столкнуться с такими последствиями:

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

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

Когда REST API можно ограничить, а когда лучше оставить как есть

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

Полное отключение имеет смысл только в редких случаях, когда вы точно знаете, что:

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

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

Самый безопасный вариант: закрыть REST API для гостей

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

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

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

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

    return $result;
} );

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

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

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

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

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

Создайте файл, например disable-rest-api.php, в папке wp-content/mu-plugins/. Если папки mu-plugins нет, её можно создать вручную. WordPress подхватывает такие плагины автоматически.

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

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

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

    return $result;
} );

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

Как отключить только часть REST API, а не весь интерфейс

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

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

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

add_filter( 'rest_endpoints', function( $endpoints ) {
    unset( $endpoints['/wp/v2/users'] );
    return $endpoints;
} );

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

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

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

Что стоит проверить вручную:

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

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

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

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

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

редактор блоков WordPress;
динамические блоки и паттерны, которые подгружают данные через JSON;
плагины с фронтенд-фильтрами, каталогами, поиском и AJAX-логикой;
внешние сервисы и интеграции, которые получают данные из WordPress по API.

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

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

Что выбрать в реальном проекте

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

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

Если вы сомневаетесь, начните с мягкого ограничения через rest_authentication_errors. Это самый практичный путь: он даёт контроль над доступом и оставляет WordPress рабочим там, где REST API действительно нужен.